Re: [PATCH] ASoC: fsl: fix -Wmaybe-uninitialized warning

[Nathan Chancellor]

On Wed, Dec 30, 2020 at 04:44:15PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> Clang points out a code path that returns an undefined value
> in an error case:
> 
> sound/soc/fsl/imx-hdmi.c:165:6: error: variable 'ret' is used uninitialized 
> whenever 'if' condition is true [-Werror,-Wsom
> etimes-uninitialized]
> if ((hdmi_out && hdmi_in) || (!hdmi_out && !hdmi_in)) {
> ^~~~
> sound/soc/fsl/imx-hdmi.c:212:9: note: uninitialized use occurs here
> return ret;
> 
> The driver returns -EINVAL for other broken DT properties, so do
> it the same way here.
> 
> Fixes: 6a5f850aa83a ("ASoC: fsl: Add imx-hdmi machine driver")
> Signed-off-by: Arnd Bergmann 

Reviewed-by: Nathan Chancellor 

> ---
>  sound/soc/fsl/imx-hdmi.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/sound/soc/fsl/imx-hdmi.c b/sound/soc/fsl/imx-hdmi.c
> index 2c2a76a71940..ede4a9ad1054 100644
> --- a/sound/soc/fsl/imx-hdmi.c
> +++ b/sound/soc/fsl/imx-hdmi.c
> @@ -164,6 +164,7 @@ static int imx_hdmi_probe(struct platform_device *pdev)
>  
>   if ((hdmi_out && hdmi_in) || (!hdmi_out && !hdmi_in)) {
>   dev_err(&pdev->dev, "Invalid HDMI DAI link\n");
> + ret = -EINVAL;
>   goto fail;
>   }
>  
> -- 
> 2.29.2
> 

Re: [PATCH v6 3/8] power: supply: max8997_charger: Set CHARGER current limit

[Krzysztof Kozlowski]

On Thu, Dec 31, 2020 at 07:19:07AM +, Timon Baetz wrote:
> On Thu, 31 Dec 2020 07:22:22 +0800, kernel test robot wrote:
> > Hi Timon,
> > 
> > Thank you for the patch! Yet something to improve:
> > 
> > [auto build test ERROR on regulator/for-next]
> > [also build test ERROR on pinctrl-samsung/for-next krzk/for-next v5.11-rc1 
> > next-20201223]
> > [cannot apply to robh/for-next]
> > [If your patch is applied to the wrong git tree, kindly drop us a note.
> > And when submitting patch, we suggest to use '--base' as documented in
> > https://git-scm.com/docs/git-format-patch]
> > 
> > url:
> > https://github.com/0day-ci/linux/commits/Timon-Baetz/extcon-max8997-Add-CHGINS-and-CHGRM-interrupt-handling/20201231-045812
> > base:   
> > https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 
> > for-next
> > config: arm-randconfig-r004-20201230 (attached as .config)
> > compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
> > 3c0d36f977d9e012b245c796ddc8596ac3af659b)
> > reproduce (this is a W=1 build):
> > wget 
> > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
> > ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > # install arm cross compiling tool for clang build
> > # apt-get install binutils-arm-linux-gnueabi
> > # 
> > https://github.com/0day-ci/linux/commit/3a597219bbfc1f9a0b65b9662b7b95bbb7cf728f
> >     git remote add linux-review https://github.com/0day-ci/linux
> > git fetch --no-tags linux-review 
> > Timon-Baetz/extcon-max8997-Add-CHGINS-and-CHGRM-interrupt-handling/20201231-045812
> > git checkout 3a597219bbfc1f9a0b65b9662b7b95bbb7cf728f
> > # save the attached .config to linux build tree
> > COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm
> > 
> > If you fix the issue, kindly add following tag as appropriate
> > Reported-by: kernel test robot 
> > 
> > All errors (new ones prefixed by >>):
> > 
> > >> drivers/power/supply/max8997_charger.c:261:9: error: implicit 
> > >> declaration of function 'devm_extcon_register_notifier_all' 
> > >> [-Werror,-Wimplicit-function-declaration]  
> >ret = devm_extcon_register_notifier_all(&pdev->dev, 
> > charger->edev,
> >  ^
> >drivers/power/supply/max8997_charger.c:261:9: note: did you mean 
> > 'devm_extcon_register_notifier'?
> >include/linux/extcon.h:263:19: note: 'devm_extcon_register_notifier' 
> > declared here
> >static inline int devm_extcon_register_notifier(struct device *dev,
> >  ^
> >1 error generated.
> 
> This is failing because CONFIG_EXTCON is not set and *_all() don't have
> stub implementations in extcon.h. Should I add a fix for it in this
> series?

It is not problem of your patchset, so up to you.  After your changes
the driver still can work fine without CONFIG_EXTCON and CONFIG_REGULATOR.

Best regards,
Krzysztof

Re: sound

[Greg Kroah-Hartman]

On Wed, Dec 30, 2020 at 07:10:16PM +0100, Christian Labisch wrote:
> Update :
> 
> I've just tested the kernel 5.10.4 from ELRepo.
> Unfortunately nothing changed - still no sound.

Ah, sad.  Can you run 'git bisect' between 5.9 and 5.10 to determine the
commit that caused the problem?

thanks,

greg k-h

Re: [PATCH v9 1/4] dt-bindings: mfd: Fix schema warnings for pwm-leds

[Lee Jones]

On Wed, 30 Dec 2020, Pavel Machek wrote:

> Hi!
> 
> > The node names for devices using the pwm-leds driver follow a certain
> > naming scheme (now).  Parent node name is not enforced, but recommended
> > by DT project.
> > 
> >   DTC Documentation/devicetree/bindings/mfd/iqs62x.example.dt.yaml
> >   CHECK   Documentation/devicetree/bindings/mfd/iqs62x.example.dt.yaml
> > /home/alex/build/linux/Documentation/devicetree/bindings/mfd/iqs62x.example.dt.yaml:
> >  pwmleds: 'panel' does not match any of the regexes: '^led(-[0-9a-f]+)?$', 
> > 'pinctrl-[0-9]+'
> > From schema: 
> > /home/alex/src/linux/leds/Documentation/devicetree/bindings/leds/leds-pwm.yaml
> > 
> > Signed-off-by: Alexander Dahl 
> > Acked-by: Jeff LaBundy 
> > Acked-by: Rob Herring 
> 
> Thanks, applied.

Sorry, what?

Applied to what tree?

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH 5.10 134/717] spi: dw: fix build error by selecting MULTIPLEXER

[Serge Semin]

Hello Greg,
The next patch has been created to supersede the one you've applied:
https://lore.kernel.org/linux-spi/20201127144612.4204-1-sergey.se...@baikalelectronics.ru/
Mark has already merged it in his repo.

-Sergey

On Mon, Dec 28, 2020 at 01:42:12PM +0100, Greg Kroah-Hartman wrote:
> From: Randy Dunlap 
> 
> [ Upstream commit 1241f0787578136ab58f49adc52f2dcd2bbc4bf2 ]
> 
> Fix build error for spi-dw-bt1.o by selecting MULTIPLEXER.
> 
> hppa-linux-ld: drivers/spi/spi-dw-bt1.o: in function `dw_spi_bt1_sys_init':
> (.text+0x1ac): undefined reference to `devm_mux_control_get'
> 
> Fixes: abf00907538e ("spi: dw: Add Baikal-T1 SPI Controller glue driver")
> Reported-by: kernel test robot 
> Signed-off-by: Randy Dunlap 
> Cc: Serge Semin 
> Cc: Ramil Zaripov 
> Cc: Mark Brown 
> Cc: linux-...@vger.kernel.org
> Acked-by: Serge Semin 
> Link: https://lore.kernel.org/r/20201116040721.8001-1-rdun...@infradead.org
> Signed-off-by: Mark Brown 
> Signed-off-by: Sasha Levin 
> ---
>  drivers/spi/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
> index 5cff60de8e834..3fd16b7f61507 100644
> --- a/drivers/spi/Kconfig
> +++ b/drivers/spi/Kconfig
> @@ -255,6 +255,7 @@ config SPI_DW_MMIO
>  config SPI_DW_BT1
>   tristate "Baikal-T1 SPI driver for DW SPI core"
>   depends on MIPS_BAIKAL_T1 || COMPILE_TEST
> + select MULTIPLEXER
>   help
> Baikal-T1 SoC is equipped with three DW APB SSI-based MMIO SPI
> controllers. Two of them are pretty much normal: with IRQ, DMA,
> -- 
> 2.27.0
> 
> 
> 

Re: [PATCH 5.10 134/717] spi: dw: fix build error by selecting MULTIPLEXER

[Greg Kroah-Hartman]

On Thu, Dec 31, 2020 at 11:49:56AM +0300, Serge Semin wrote:
> Hello Greg,
> The next patch has been created to supersede the one you've applied:
> https://lore.kernel.org/linux-spi/20201127144612.4204-1-sergey.se...@baikalelectronics.ru/
> Mark has already merged it in his repo.

Ok, so should that one be queued up as well?  Let us know the git commit
id of it when it reaches Linus's kernel and we will be glad to take it.

thanks,

greg k-h

[PATCH] extcon: Add stubs for extcon_register_notifier_all() functions

[Krzysztof Kozlowski]

Add stubs for extcon_register_notifier_all() function for !CONFIG_EXTCON
case.  This is useful for compile testing and for drivers which use
EXTCON but do not require it (therefore do not depend on CONFIG_EXTCON).

Fixes: 815429b39d94 ("extcon: Add new extcon_register_notifier_all() to monitor 
all external connectors")
Reported-by: kernel test robot 
Signed-off-by: Krzysztof Kozlowski 
---
 include/linux/extcon.h | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/include/linux/extcon.h b/include/linux/extcon.h
index fd183fb9c20f..0c19010da77f 100644
--- a/include/linux/extcon.h
+++ b/include/linux/extcon.h
@@ -271,6 +271,29 @@ static inline  void devm_extcon_unregister_notifier(struct 
device *dev,
struct extcon_dev *edev, unsigned int id,
struct notifier_block *nb) { }
 
+static inline int extcon_register_notifier_all(struct extcon_dev *edev,
+  struct notifier_block *nb)
+{
+   return 0;
+}
+
+static inline int extcon_unregister_notifier_all(struct extcon_dev *edev,
+struct notifier_block *nb)
+{
+   return 0;
+}
+
+static inline int devm_extcon_register_notifier_all(struct device *dev,
+   struct extcon_dev *edev,
+   struct notifier_block *nb)
+{
+   return 0;
+}
+
+static inline void devm_extcon_unregister_notifier_all(struct device *dev,
+  struct extcon_dev *edev,
+  struct notifier_block 
*nb) { }
+
 static inline struct extcon_dev *extcon_get_extcon_dev(const char *extcon_name)
 {
return ERR_PTR(-ENODEV);
-- 
2.25.1

[PATCH] iio: adc: stm32-dfsdm: Remove redundant null check before clk_disable_unprepare

[Xu Wang]

ecause clk_disable_unprepare() already checked NULL clock parameter,
so the additional check is unnecessary, just remove it.

Signed-off-by: Xu Wang 
---
 drivers/iio/adc/stm32-dfsdm-core.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/iio/adc/stm32-dfsdm-core.c 
b/drivers/iio/adc/stm32-dfsdm-core.c
index 42a7377704a4..bb925a11c8ae 100644
--- a/drivers/iio/adc/stm32-dfsdm-core.c
+++ b/drivers/iio/adc/stm32-dfsdm-core.c
@@ -117,8 +117,7 @@ static void stm32_dfsdm_clk_disable_unprepare(struct 
stm32_dfsdm *dfsdm)
 {
struct dfsdm_priv *priv = to_stm32_dfsdm_priv(dfsdm);
 
-   if (priv->aclk)
-   clk_disable_unprepare(priv->aclk);
+   clk_disable_unprepare(priv->aclk);
clk_disable_unprepare(priv->clk);
 }
 
-- 
2.17.1

Re: [PATCH v6 3/8] power: supply: max8997_charger: Set CHARGER current limit

[Krzysztof Kozlowski]

On Wed, Dec 30, 2020 at 08:52:15PM +, Timon Baetz wrote:
> Register for extcon notification and set charging current depending on
> the detected cable type. Current values are taken from vendor kernel,
> where most charger types end up setting 650mA [0].
> 
> Also enable and disable the CHARGER regulator based on extcon events.
> 
> [0] 
> https://github.com/krzk/linux-vendor-backup/blob/samsung/galaxy-s2-epic-4g-touch-sph-d710-exynos4210-dump/drivers/misc/max8997-muic.c#L1675-L1678
> 
> Signed-off-by: Timon Baetz 
> ---
> v6: dev_info() instead of dev_err().
> v5: Use devm_regulator_get_optional(), dev_err() on failure.
> dev_err() on extcon_get_edev_by_phandle() failure.
> v4: Make extcon and charger-supply optional.
> v3: Split MFD change.
> return on regulator_set_current_limit() failure.
> v2: Split DTS changes.
> Add missing include.
> Rename charger_data members.
> Disable regulator on regulator_set_current_limit() failure.
> Fix ret declaration.
> Remove unneeded variables.
> Don't dev_err() on deferral.
> Get regulator and extcon from DTS.
> Use devm_regulator_get(). 
> Fix indentation.



Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

Re: [PATCH RFC] KVM: arm64: vgic: Decouple the check of the EnableLPIs bit from the ITS LPI translation

[Marc Zyngier]

Hi Shemming,

On 2020-12-31 06:28, Shenming Lu wrote:

When the EnableLPIs bit is set to 0, any ITS LPI requests in the
Redistributor would be ignored. And this check is independent from
the ITS LPI translation. So it might be better to move the check
of the EnableLPIs bit out of the LPI resolving, and also add it
to the path that uses the translation cache.


But by doing that, you are moving the overhead of checking for
EnableLPIs from the slow path (translation walk) to the fast
path (cache hit), which seems counter-productive.


Besides it seems that
by this the invalidating of the translation cache caused by the LPI
disabling is unnecessary.

Not sure if I have missed something... Thanks.


I am certainly missing the purpose of this patch.

The effect of EnableLPIs being zero is to drop the result of any
translation (a new pending bit) on the floor. Given that, it is
immaterial whether this causes a new translation or hits in the
cache, as the result is still to not pend a new interrupt.

I get the feeling that you are trying to optimise for the unusual
case where EnableLPIs is 0 *and* you have a screaming device
injecting tons of interrupt. If that is the case, I don't think
this is worth it.

Thanks,

M.



Signed-off-by: Shenming Lu 
---
 arch/arm64/kvm/vgic/vgic-its.c | 9 +
 arch/arm64/kvm/vgic/vgic-mmio-v3.c | 4 +---
 2 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/kvm/vgic/vgic-its.c 
b/arch/arm64/kvm/vgic/vgic-its.c

index 40cbaca81333..f53446bc154e 100644
--- a/arch/arm64/kvm/vgic/vgic-its.c
+++ b/arch/arm64/kvm/vgic/vgic-its.c
@@ -683,9 +683,6 @@ int vgic_its_resolve_lpi(struct kvm *kvm, struct
vgic_its *its,
if (!vcpu)
return E_ITS_INT_UNMAPPED_INTERRUPT;

-   if (!vcpu->arch.vgic_cpu.lpis_enabled)
-   return -EBUSY;
-
vgic_its_cache_translation(kvm, its, devid, eventid, ite->irq);

*irq = ite->irq;
@@ -738,6 +735,9 @@ static int vgic_its_trigger_msi(struct kvm *kvm,
struct vgic_its *its,
if (err)
return err;

+   if (!irq->target_vcpu->arch.vgic_cpu.lpis_enabled)
+   return -EBUSY;
+
if (irq->hw)
return irq_set_irqchip_state(irq->host_irq,
 IRQCHIP_STATE_PENDING, true);
@@ -757,7 +757,8 @@ int vgic_its_inject_cached_translation(struct kvm
*kvm, struct kvm_msi *msi)

db = (u64)msi->address_hi << 32 | msi->address_lo;
irq = vgic_its_check_cache(kvm, db, msi->devid, msi->data);
-   if (!irq)
+
+   if (!irq || !irq->target_vcpu->arch.vgic_cpu.lpis_enabled)
return -EWOULDBLOCK;

raw_spin_lock_irqsave(&irq->irq_lock, flags);
diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
index 15a6c98ee92f..7b0749f7660d 100644
--- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
+++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
@@ -242,10 +242,8 @@ static void vgic_mmio_write_v3r_ctlr(struct 
kvm_vcpu *vcpu,


vgic_cpu->lpis_enabled = val & GICR_CTLR_ENABLE_LPIS;

-   if (was_enabled && !vgic_cpu->lpis_enabled) {
+   if (was_enabled && !vgic_cpu->lpis_enabled)
vgic_flush_pending_lpis(vcpu);
-   vgic_its_invalidate_cache(vcpu->kvm);
-   }

if (!was_enabled && vgic_cpu->lpis_enabled)
vgic_enable_lpis(vcpu);


--
Jazz is not dead. It just smells funny...

Re: [PATCH v3 11/13] arm: dts: owl-s500-roseapplepi: Add uSD support

[Cristian Ciocaltea]

On Thu, Dec 31, 2020 at 12:57:10PM +0530, Manivannan Sadhasivam wrote:
> On Tue, Dec 29, 2020 at 11:17:26PM +0200, Cristian Ciocaltea wrote:
> > Add uSD support for RoseapplePi SBC using a fixed regulator as a
> > temporary solution until PMIC support becomes available.
> > 
> > Signed-off-by: Cristian Ciocaltea 
> 
> Reviewed-by: Manivannan Sadhasivam 

Thank you, Mani!

> Thanks,
> Mani
> 
> > ---
> > Changes in v3:
> >  - None
> > 
> >  arch/arm/boot/dts/owl-s500-roseapplepi.dts | 50 ++
> >  1 file changed, 50 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/owl-s500-roseapplepi.dts 
> > b/arch/arm/boot/dts/owl-s500-roseapplepi.dts
> > index 800edf5d2d12..fe9ae3619422 100644
> > --- a/arch/arm/boot/dts/owl-s500-roseapplepi.dts
> > +++ b/arch/arm/boot/dts/owl-s500-roseapplepi.dts
> > @@ -14,6 +14,7 @@ / {
> > model = "Roseapple Pi";
> >  
> > aliases {
> > +   mmc0 = &mmc0;
> > serial2 = &uart2;
> > };
> >  
> > @@ -25,6 +26,55 @@ memory@0 {
> > device_type = "memory";
> > reg = <0x0 0x8000>; /* 2GB */
> > };
> > +
> > +   /* Fixed regulator used in the absence of PMIC */
> > +   sd_vcc: sd-vcc {
> > +   compatible = "regulator-fixed";
> > +   regulator-name = "fixed-3.1V";
> > +   regulator-min-microvolt = <310>;
> > +   regulator-max-microvolt = <310>;
> > +   regulator-always-on;
> > +   };
> > +};
> > +
> > +&pinctrl {
> > +   mmc0_pins: mmc0-pins {
> > +   pinmux {
> > +   groups = "sd0_d0_mfp", "sd0_d1_mfp", "sd0_d2_d3_mfp",
> > +"sd0_cmd_mfp", "sd0_clk_mfp";
> > +   function = "sd0";
> > +   };
> > +
> > +   drv-pinconf {
> > +   groups = "sd0_d0_d3_drv", "sd0_cmd_drv", "sd0_clk_drv";
> > +   drive-strength = <8>;
> > +   };
> > +
> > +   bias0-pinconf {
> > +   pins = "sd0_d0", "sd0_d1", "sd0_d2",
> > +  "sd0_d3", "sd0_cmd";
> > +   bias-pull-up;
> > +   };
> > +
> > +   bias1-pinconf {
> > +   pins = "sd0_clk";
> > +   bias-pull-down;
> > +   };
> > +   };
> > +};
> > +
> > +/* uSD */
> > +&mmc0 {
> > +   status = "okay";
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <&mmc0_pins>;
> > +   no-sdio;
> > +   no-mmc;
> > +   no-1-8-v;
> > +   cd-gpios = <&pinctrl 117 GPIO_ACTIVE_LOW>;
> > +   bus-width = <4>;
> > +   vmmc-supply = <&sd_vcc>;
> > +   vqmmc-supply = <&sd_vcc>;
> >  };
> >  
> >  &twd_timer {
> > -- 
> > 2.30.0
> > 

[PATCH RFC net-next] net: hns3: debugfs add dump tm info of nodes, priority and qset

[Guangbin Huang]

To increase methods to dump more tm info, adds three debugfs commands
to dump tm info of nodes, priority and qset. And a new tm file of debugfs
is created for only dumping tm info.

Unlike previous debugfs commands, to dump each tm information, user needs
to enter two commands now. The first command writes parameters to tm and
the second command reads info from tm. For examples, to dump tm info of
priority 0, user needs to enter follow two commands:
1. echo dump priority 0 > tm
2. cat tm

The reason for adding new tm file is because we accepted Jakub Kicinski's
opinion as link https://lkml.org/lkml/2020/9/29/2101. And in order to
avoid generating too many files, we implement write ops to allow user to
input parameters.

However, If there are two or more users concurrently write parameters to
tm, parameters of the latest command will overwrite previous commands, 
this concurrency problem will confuse users, but now there is no good
method to fix it.

Signed-off-by: Guangbin Huang 
---
 drivers/net/ethernet/hisilicon/hns3/hnae3.h|   9 +
 drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c | 117 ++
 drivers/net/ethernet/hisilicon/hns3/hns3_enet.h|   6 +
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.h |   1 +
 .../ethernet/hisilicon/hns3/hns3pf/hclge_debugfs.c | 250 +
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c|   1 +
 .../ethernet/hisilicon/hns3/hns3pf/hclge_main.h|   2 +
 .../net/ethernet/hisilicon/hns3/hns3pf/hclge_tm.h  |  26 +++
 8 files changed, 412 insertions(+)

diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h 
b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
index 912c51e..08a30de 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
+++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
@@ -243,6 +243,10 @@ struct hnae3_vector_info {
int vector;
 };
 
+enum hnae3_dbg_module_type {
+   HNAE3_DBG_MODULE_TYPE_TM,
+};
+
 #define HNAE3_RING_TYPE_B 0
 #define HNAE3_RING_TYPE_TX 0
 #define HNAE3_RING_TYPE_RX 1
@@ -454,6 +458,8 @@ struct hnae3_ae_dev {
  *   Configure the default MAC for specified VF
  * get_module_eeprom
  *   Get the optical module eeprom info.
+ * dbg_read_cmd
+ *   Execute debugfs read command.
  */
 struct hnae3_ae_ops {
int (*init_ae_dev)(struct hnae3_ae_dev *ae_dev);
@@ -609,6 +615,8 @@ struct hnae3_ae_ops {
int (*add_arfs_entry)(struct hnae3_handle *handle, u16 queue_id,
  u16 flow_id, struct flow_keys *fkeys);
int (*dbg_run_cmd)(struct hnae3_handle *handle, const char *cmd_buf);
+   int (*dbg_read_cmd)(struct hnae3_handle *handle, const char *cmd_buf,
+   char *buf, int len);
pci_ers_result_t (*handle_hw_ras_error)(struct hnae3_ae_dev *ae_dev);
bool (*get_hw_reset_stat)(struct hnae3_handle *handle);
bool (*ae_dev_resetting)(struct hnae3_handle *handle);
@@ -734,6 +742,7 @@ struct hnae3_handle {
 
u8 netdev_flags;
struct dentry *hnae3_dbgfs;
+   int dbgfs_type;
 
/* Network interface message level enabled bits */
u32 msg_enable;
diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c 
b/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c
index dc9a857..bdca7d4 100644
--- a/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c
+++ b/drivers/net/ethernet/hisilicon/hns3/hns3_debugfs.c
@@ -12,6 +12,10 @@
 
 static struct dentry *hns3_dbgfs_root;
 
+#define HNS3_HELP_INFO "help"
+
+#define HNS3_DBG_MODULE_NAME_TM"tm"
+
 static int hns3_dbg_queue_info(struct hnae3_handle *h,
   const char *cmd_buf)
 {
@@ -305,6 +309,22 @@ static void hns3_dbg_help(struct hnae3_handle *h)
dev_info(&h->pdev->dev, "%s", printf_buf);
 }
 
+static void hns3_dbg_tm_help(struct hnae3_handle *h, char *buf, int len)
+{
+   struct hnae3_ae_dev *ae_dev = pci_get_drvdata(h->pdev);
+   int pos;
+
+   pos = scnprintf(buf, len, "available commands:\n");
+
+   if (!hns3_is_phys_func(h->pdev))
+   return;
+
+   if (ae_dev->dev_version > HNAE3_DEVICE_VERSION_V2)
+   pos += scnprintf(buf + pos, len - pos, "dump nodes\n");
+   pos += scnprintf(buf + pos, len - pos, "dump priority \n");
+   pos += scnprintf(buf + pos, len - pos, "dump qset \n");
+}
+
 static void hns3_dbg_dev_caps(struct hnae3_handle *h)
 {
struct hnae3_ae_dev *ae_dev = pci_get_drvdata(h->pdev);
@@ -444,6 +464,93 @@ static ssize_t hns3_dbg_cmd_write(struct file *filp, const 
char __user *buffer,
return count;
 }
 
+static ssize_t hns3_dbg_tm_read(struct file *filp, char __user *buffer,
+   size_t count, loff_t *ppos)
+{
+   struct hnae3_handle *handle = filp->private_data;
+   const struct hnae3_ae_ops *ops = handle->ae_algo->ops;
+   struct hns3_nic_priv *priv  = handle->priv;
+   char *cmd_buf, *read_buf;
+   ssize_t size = 0;
+   int ret = 0;
+
+   if (strncmp(filp->f_path.

Re: [PATCH RESEND v2 1/2] dt-bindings: spi: Realtek RTL838x/RTL839x SPI controller

[Bert Vermeulen]

On 12/30/20 2:51 PM, Mark Brown wrote:
> On Wed, Dec 30, 2020 at 12:19:03AM +0100, Bert Vermeulen wrote:
> 
>> +properties:
>> +  compatible:
>> +const: realtek,spi
> 
> It is possibled Realtek might make other SPI controllers, there should
> be some more specific name such as a compatible for each SoC that the
> controller appears in or an IP name if one is known.

Mark,

Good call. We're changing all the Realtek RTL838x/RTL839x stuff to some
variation of "realtek-rtl", in this case "realtek,rtl-spi". The "rtl"
prefix to Realtek SoCs fits the bill. Will resubmit.


-- 
Bert Vermeulen
b...@biot.com

Re: [PATCH 5.10 134/717] spi: dw: fix build error by selecting MULTIPLEXER

[Serge Semin]

On Thu, Dec 31, 2020 at 09:51:21AM +0100, Greg Kroah-Hartman wrote:
> On Thu, Dec 31, 2020 at 11:49:56AM +0300, Serge Semin wrote:
> > Hello Greg,
> > The next patch has been created to supersede the one you've applied:
> > https://lore.kernel.org/linux-spi/20201127144612.4204-1-sergey.se...@baikalelectronics.ru/
> > Mark has already merged it in his repo.
> 

> Ok, so should that one be queued up as well?  Let us know the git commit
> id of it when it reaches Linus's kernel and we will be glad to take it.

I believe it is already there:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7218838109fef61cdec988ff728e902d434c9cc5
Yeah, it's better to queue that patch up too, otherwise the build
error will be indeed fixed by the commit you've merged in, but the
probe procedure will still always fail.

-Sergey

> 
> thanks,
> 
> greg k-h

Re: [PATCH v3 00/13] Add CMU/RMU/DMA/MMC/I2C support for Actions Semi

[Cristian Ciocaltea]

On Thu, Dec 31, 2020 at 01:24:35PM +0530, Manivannan Sadhasivam wrote:
> On Tue, Dec 29, 2020 at 11:17:15PM +0200, Cristian Ciocaltea wrote:
> > Hi,
> > 
> > This patchset brings a series of improvements for the Actions Semi S500
> > SoCs family, by adding support for Clock & Reset Management Units, DMA,
> > MMC, I2C & SIRQ controllers.
> > 
> > Please note the patches consist mostly of DTS and bindings/compatibles
> > changes, since all the work they depend on has been already merged,
> > i.e. clock fixes/additions, pinctrl driver, sirq driver.
> > 
> > For the moment, I have only enabled the features I could test on
> > RoseapplePi SBC.
> > 
> 
> Applied all patches except the 2 dmaengine patches for v5.12. Andreas, please
> let me know if you want to do the PR this time. Else I'll proceed.

Thank you, Mani!
The dmaengine patches should be picked up by Vinod, right?

> Thanks,
> Mani
> 
> > Thanks,
> > Cristi
> > 
> > Changes in v3:
> > - Squashed 'arm: dts: owl-s500-roseapplepi: Use UART clock from CMU' with
> >   'arm: dts: owl-s500: Set CMU clocks for UARTs', according to Mani's review
> > - Rebased series on v5.11-rc1 and dropped the already merged patches:
> >  * dt-bindings: mmc: owl: Add compatible string for Actions Semi S500 SoC
> >  * dt-bindings: i2c: owl: Convert Actions Semi Owl binding to a schema
> >  * MAINTAINERS: Update entry for Actions Semi Owl I2C binding
> >  * i2c: owl: Add compatible for the Actions Semi S500 I2C controller
> > 
> > Changes in v2:
> > - Added new bindings/compatibles for S500 DMA, MMC & I2C controllers
> > - Added support for the SIRQ controller
> > - Added new entries in MAINTAINERS
> > - Updated naming of some patches in v1
> > 
> > Cristian Ciocaltea (13):
> >   arm: dts: owl-s500: Add Clock Management Unit
> >   arm: dts: owl-s500: Set CMU clocks for UARTs
> >   arm: dts: owl-s500: Add Reset controller
> >   dt-bindings: dma: owl: Add compatible string for Actions Semi S500 SoC
> >   dmaengine: owl: Add compatible for the Actions Semi S500 DMA
> > controller
> >   arm: dts: owl-s500: Add DMA controller
> >   arm: dts: owl-s500: Add pinctrl & GPIO support
> >   arm: dts: owl-s500: Add MMC support
> >   arm: dts: owl-s500: Add I2C support
> >   arm: dts: owl-s500: Add SIRQ controller
> >   arm: dts: owl-s500-roseapplepi: Add uSD support
> >   arm: dts: owl-s500-roseapplepi: Add I2C pinctrl configuration
> >   MAINTAINERS: Add linux-actions ML for Actions Semi Arch
> > 
> >  .../devicetree/bindings/dma/owl-dma.yaml  |   7 +-
> >  MAINTAINERS   |   1 +
> >  arch/arm/boot/dts/owl-s500-cubieboard6.dts|   7 -
> >  .../arm/boot/dts/owl-s500-guitar-bb-rev-b.dts |   7 -
> >  .../arm/boot/dts/owl-s500-labrador-base-m.dts |   7 -
> >  arch/arm/boot/dts/owl-s500-roseapplepi.dts|  97 +++-
> >  arch/arm/boot/dts/owl-s500-sparky.dts |   7 -
> >  arch/arm/boot/dts/owl-s500.dtsi   | 140 ++
> >  drivers/dma/owl-dma.c |   3 +-
> >  9 files changed, 239 insertions(+), 37 deletions(-)
> > 
> > -- 
> > 2.30.0
> > 

Re: [PATCH 5.10 134/717] spi: dw: fix build error by selecting MULTIPLEXER

[Greg Kroah-Hartman]

On Thu, Dec 31, 2020 at 12:10:34PM +0300, Serge Semin wrote:
> On Thu, Dec 31, 2020 at 09:51:21AM +0100, Greg Kroah-Hartman wrote:
> > On Thu, Dec 31, 2020 at 11:49:56AM +0300, Serge Semin wrote:
> > > Hello Greg,
> > > The next patch has been created to supersede the one you've applied:
> > > https://lore.kernel.org/linux-spi/20201127144612.4204-1-sergey.se...@baikalelectronics.ru/
> > > Mark has already merged it in his repo.
> > 
> 
> > Ok, so should that one be queued up as well?  Let us know the git commit
> > id of it when it reaches Linus's kernel and we will be glad to take it.
> 
> I believe it is already there:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7218838109fef61cdec988ff728e902d434c9cc5
> Yeah, it's better to queue that patch up too, otherwise the build
> error will be indeed fixed by the commit you've merged in, but the
> probe procedure will still always fail.

Ok, now queued up, thanks for letting us know.

greg k-h

Re: [PATCH 00/10] Cover letter: fix a race in release_task when flushing the dentry

[Greg Kroah-Hartman]

On Thu, Dec 17, 2020 at 10:26:23AM +0800, Wen Yang wrote:
> 
> 
> 在 2020/12/4 上午2:31, Wen Yang 写道:
> > The dentries such as /proc//ns/ have the DCACHE_OP_DELETE flag, they
> > should be deleted when the process exits.
> > 
> > Suppose the following race appears：
> > 
> > release_task     dput
> > -> proc_flush_task
> >       -> dentry->d_op->d_delete(dentry)
> > -> __exit_signal
> >   -> dentry->d_lockref.count--  and return.
> > 
> > In the proc_flush_task(), if another process is using this dentry, it will
> > not be deleted. At the same time, in dput(), d_op->d_delete() can be 
> > executed
> > before __exit_signal(pid has not been hashed), d_delete returns false, so
> > this dentry still cannot be deleted.
> > 
> > This dentry will always be cached (although its count is 0 and the
> > DCACHE_OP_DELETE flag is set), its parent denry will also be cached too, and
> > these dentries can only be deleted when drop_caches is manually triggered.
> > 
> > This will result in wasted memory. What's more troublesome is that these
> > dentries reference pid, according to the commit f333c700c610 ("pidns: Add a
> > limit on the number of pid namespaces"), if the pid cannot be released, it
> > may result in the inability to create a new pid_ns.
> > 
> > This problem occurred in our cluster environment (Linux 4.9 LTS).
> > We could reproduce it by manually constructing a test program + adding some
> > debugging switches in the kernel:
> > * A test program to open the directory (/proc//ns) [1]
> > * Adding some debugging switches to the kernel, adding a delay between
> > proc_flush_task and __exit_signal in release_task() [2]
> > 
> > The test process is as follows:
> > 
> > A, terminal #1
> > 
> > Turn on the debug switch:
> > echo 1> /proc/sys/vm/dentry_debug_trace
> > 
> > Execute the following unshare command:
> > sudo unshare --pid --fork --mount-proc bash
> > 
> > 
> > B, terminal #2
> > 
> > Find the pid of the unshare process:
> > 
> > # pstree -p | grep unshare
> > | `-sshd(716)---bash(718)--sudo(816)---unshare(817)---bash(818)
> > 
> > 
> > Find the corresponding dentry:
> > # dmesg | grep pid=818
> > [70.424722] XXX proc_pid_instantiate:3119 pid=818 tid=818 
> > entry=818/8802c7b670e8
> > 
> > 
> > C, terminal #3
> > 
> > Execute the opendir program, it will always open the /proc/818/ns/ 
> > directory:
> > 
> > # ./a.out /proc/818/ns/
> > pid: 876
> > .
> > ..
> > net
> > uts
> > ipc
> > pid
> > user
> > mnt
> > cgroup
> > 
> > D, go back to terminal #2
> > 
> > Turn on the debugging switches to construct the race:
> > # echo 818> /proc/sys/vm/dentry_debug_pid
> > # echo 1> /proc/sys/vm/dentry_debug_delay
> > 
> > Kill the unshare process (pid 818). Since the debugging switches have been
> > turned on, it will get stuck in release_task():
> > # kill -9 818
> > 
> > Then kill the process that opened the /proc/818/ns/ directory:
> > # kill -9 876
> > 
> > Then turn off these debugging switches to allow the 818 process to exit:
> > # echo 0> /proc/sys/vm/dentry_debug_delay
> > # echo 0> /proc/sys/vm/dentry_debug_pid
> > 
> > Checking the dmesg, we will find that the dentry(/proc/818/ns) ’s count is 
> > 0,
> > and the flag is 2800cc (#define DCACHE_OP_DELETE 0x0008), but it is 
> > still
> > cached:
> > # dmesg | grep 8802a3999548
> > …
> > [565.559156] XXX dput:853 dentry=ns/8802bea7b528, flag=2800cc, cnt=0, 
> > inode=8802b38c2010, pdentry=818/8802c7b670e8, pflag=20008c, pcnt=1, 
> > pinode=8802c7812010, keywords: be cached
> > 
> > 
> > It could also be verified via the crash tool:
> > 
> > crash> dentry.d_flags,d_iname,d_inode,d_lockref -x  8802bea7b528
> >d_flags = 0x2800cc
> >d_iname = "ns\000"
> >d_inode = 0x8802b38c2010
> >d_lockref = {
> >  {
> >lock_count = 0x0,
> >{
> >  lock = {
> >{
> >  rlock = {
> >raw_lock = {
> >  {
> >val = {
> >  counter = 0x0
> >},
> >{
> >  locked = 0x0,
> >  pending = 0x0
> >},
> >{
> >  locked_pending = 0x0,
> >  tail = 0x0
> >}
> >  }
> >}
> >  }
> >}
> >  },
> >  count = 0x0
> >}
> >  }
> >}
> > crash> kmem  8802bea7b528
> > CACHE OBJSIZE  ALLOCATED TOTAL  SLABS  SSIZE  NAME
> > 8802dd5f5900  192  23663 2613087116k  dentry
> >SLAB  MEMORYNODE  TOTAL  ALLOCATED  FREE
> >ea000afa9e00  8802bea78000 0 30 25 5
> >FREE / [ALLOCATED]
> >[8802bea7b520]
> > 
> >PAGEPHYSICAL  MAPPING   INDEX CNT FLAGS

Re: Time to re-enable Runtime PM per default for PCI devcies?

[Heiner Kallweit]

On 31.12.2020 05:07, Lukas Wunner wrote:
> On Wed, Dec 30, 2020 at 11:56:04PM +0100, Heiner Kallweit wrote:
>> --- a/drivers/pci/pci.c
>> +++ b/drivers/pci/pci.c
>> @@ -3024,7 +3024,9 @@ void pci_pm_init(struct pci_dev *dev)
>>  u16 status;
>>  u16 pmc;
>>  
>> -pm_runtime_forbid(&dev->dev);
>> +if (pci_acpi_forbid_runtime_pm())
>> +pm_runtime_forbid(&dev->dev);
>> +
> 
> Generic PCI code usually does not call ACPI-specific functions directly,
> but rather through a pci_platform_pm_ops callback.
> 
> FWIW, if platform_pci_power_manageable() returns true, it can probably
> be assumed that allowing runtime PM by default is okay.  So as a first
> step, you may want to call that instead of adding a new callback.
> 
I don't think that's sufficient. Most likely all the broken old systems
return true for platform_pci_power_manageable(). So yes, most likely
we'd need a new callback if we want to have the platform ops abstraction.
But it could be an optional callback, something like: forbid_runtime_pm
The question is just: is it worth it?

By the way: pci_set_platform_pm() returns an error if a callback isn't
set, but no existing caller bothers to check the return code.

> Thanks,
> 
> Lukas
> 
Heiner

Re: [PATCH v9 1/4] dt-bindings: mfd: Fix schema warnings for pwm-leds

[Pavel Machek]

Hi!

> > > The node names for devices using the pwm-leds driver follow a certain
> > > naming scheme (now).  Parent node name is not enforced, but recommended
> > > by DT project.
> > > 
> > >   DTC Documentation/devicetree/bindings/mfd/iqs62x.example.dt.yaml
> > >   CHECK   Documentation/devicetree/bindings/mfd/iqs62x.example.dt.yaml
> > > /home/alex/build/linux/Documentation/devicetree/bindings/mfd/iqs62x.example.dt.yaml:
> > >  pwmleds: 'panel' does not match any of the regexes: 
> > > '^led(-[0-9a-f]+)?$', 'pinctrl-[0-9]+'
> > > From schema: 
> > > /home/alex/src/linux/leds/Documentation/devicetree/bindings/leds/leds-pwm.yaml
> > > 
> > > Signed-off-by: Alexander Dahl 
> > > Acked-by: Jeff LaBundy 
> > > Acked-by: Rob Herring 
> > 
> > Thanks, applied.
> 
> Sorry, what?
> 
> Applied to what tree?

I took it to (local copy) of leds-next tree on. But now I realised it
is mfd, not a LED patch, so I undone that. Sorry for the confusion.

Anyway, patch still looks good to me:

Acked-by: Pavel Machek 
Pavel
-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: Digital signature

[PATCH] drm/msm/mdp4: Remove redundant null check before clk_prepare_enable/clk_disable_unprepare

[Xu Wang]

Because clk_prepare_enable() and clk_disable_unprepare() already checked
NULL clock parameter, so the additional checks are unnecessary, just
remove them.

Signed-off-by: Xu Wang 
---
 drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 18 ++
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c 
b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
index 3d729270bde1..696a22d571ad 100644
--- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c
@@ -207,12 +207,9 @@ int mdp4_disable(struct mdp4_kms *mdp4_kms)
DBG("");
 
clk_disable_unprepare(mdp4_kms->clk);
-   if (mdp4_kms->pclk)
-   clk_disable_unprepare(mdp4_kms->pclk);
-   if (mdp4_kms->lut_clk)
-   clk_disable_unprepare(mdp4_kms->lut_clk);
-   if (mdp4_kms->axi_clk)
-   clk_disable_unprepare(mdp4_kms->axi_clk);
+   clk_disable_unprepare(mdp4_kms->pclk);
+   clk_disable_unprepare(mdp4_kms->lut_clk);
+   clk_disable_unprepare(mdp4_kms->axi_clk);
 
return 0;
 }
@@ -222,12 +219,9 @@ int mdp4_enable(struct mdp4_kms *mdp4_kms)
DBG("");
 
clk_prepare_enable(mdp4_kms->clk);
-   if (mdp4_kms->pclk)
-   clk_prepare_enable(mdp4_kms->pclk);
-   if (mdp4_kms->lut_clk)
-   clk_prepare_enable(mdp4_kms->lut_clk);
-   if (mdp4_kms->axi_clk)
-   clk_prepare_enable(mdp4_kms->axi_clk);
+   clk_prepare_enable(mdp4_kms->pclk);
+   clk_prepare_enable(mdp4_kms->lut_clk);
+   clk_prepare_enable(mdp4_kms->axi_clk);
 
return 0;
 }
-- 
2.17.1

[PATCH] drm/msm/mdp5: Remove redundant null check before clk_prepare_enable/clk_disable_unprepare

[Xu Wang]

Because clk_prepare_enable() and clk_disable_unprepare() already checked
NULL clock parameter, so the additional checks are unnecessary, just
remove them.

Signed-off-by: Xu Wang 
---
 drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c  | 18 ++
 drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c | 12 
 2 files changed, 10 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 15aed45022bc..8d373d2ffd51 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
@@ -303,15 +303,12 @@ static int mdp5_disable(struct mdp5_kms *mdp5_kms)
mdp5_kms->enable_count--;
WARN_ON(mdp5_kms->enable_count < 0);
 
-   if (mdp5_kms->tbu_rt_clk)
-   clk_disable_unprepare(mdp5_kms->tbu_rt_clk);
-   if (mdp5_kms->tbu_clk)
-   clk_disable_unprepare(mdp5_kms->tbu_clk);
+   clk_disable_unprepare(mdp5_kms->tbu_rt_clk);
+   clk_disable_unprepare(mdp5_kms->tbu_clk);
clk_disable_unprepare(mdp5_kms->ahb_clk);
clk_disable_unprepare(mdp5_kms->axi_clk);
clk_disable_unprepare(mdp5_kms->core_clk);
-   if (mdp5_kms->lut_clk)
-   clk_disable_unprepare(mdp5_kms->lut_clk);
+   clk_disable_unprepare(mdp5_kms->lut_clk);
 
return 0;
 }
@@ -325,12 +322,9 @@ static int mdp5_enable(struct mdp5_kms *mdp5_kms)
clk_prepare_enable(mdp5_kms->ahb_clk);
clk_prepare_enable(mdp5_kms->axi_clk);
clk_prepare_enable(mdp5_kms->core_clk);
-   if (mdp5_kms->lut_clk)
-   clk_prepare_enable(mdp5_kms->lut_clk);
-   if (mdp5_kms->tbu_clk)
-   clk_prepare_enable(mdp5_kms->tbu_clk);
-   if (mdp5_kms->tbu_rt_clk)
-   clk_prepare_enable(mdp5_kms->tbu_rt_clk);
+   clk_prepare_enable(mdp5_kms->lut_clk);
+   clk_prepare_enable(mdp5_kms->tbu_clk);
+   clk_prepare_enable(mdp5_kms->tbu_rt_clk);
 
return 0;
 }
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c 
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c
index 09bd46ad820b..02c6c4b68c68 100644
--- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c
+++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_mdss.c
@@ -137,10 +137,8 @@ static int mdp5_mdss_enable(struct msm_mdss *mdss)
DBG("");
 
clk_prepare_enable(mdp5_mdss->ahb_clk);
-   if (mdp5_mdss->axi_clk)
-   clk_prepare_enable(mdp5_mdss->axi_clk);
-   if (mdp5_mdss->vsync_clk)
-   clk_prepare_enable(mdp5_mdss->vsync_clk);
+   clk_prepare_enable(mdp5_mdss->axi_clk);
+   clk_prepare_enable(mdp5_mdss->vsync_clk);
 
return 0;
 }
@@ -150,10 +148,8 @@ static int mdp5_mdss_disable(struct msm_mdss *mdss)
struct mdp5_mdss *mdp5_mdss = to_mdp5_mdss(mdss);
DBG("");
 
-   if (mdp5_mdss->vsync_clk)
-   clk_disable_unprepare(mdp5_mdss->vsync_clk);
-   if (mdp5_mdss->axi_clk)
-   clk_disable_unprepare(mdp5_mdss->axi_clk);
+   clk_disable_unprepare(mdp5_mdss->vsync_clk);
+   clk_disable_unprepare(mdp5_mdss->axi_clk);
clk_disable_unprepare(mdp5_mdss->ahb_clk);
 
return 0;
-- 
2.17.1

Re: Time to re-enable Runtime PM per default for PCI devcies?

[Heiner Kallweit]

On 31.12.2020 10:38, Heiner Kallweit wrote:
> On 31.12.2020 05:07, Lukas Wunner wrote:
>> On Wed, Dec 30, 2020 at 11:56:04PM +0100, Heiner Kallweit wrote:
>>> --- a/drivers/pci/pci.c
>>> +++ b/drivers/pci/pci.c
>>> @@ -3024,7 +3024,9 @@ void pci_pm_init(struct pci_dev *dev)
>>> u16 status;
>>> u16 pmc;
>>>  
>>> -   pm_runtime_forbid(&dev->dev);
>>> +   if (pci_acpi_forbid_runtime_pm())
>>> +   pm_runtime_forbid(&dev->dev);
>>> +
>>
>> Generic PCI code usually does not call ACPI-specific functions directly,
>> but rather through a pci_platform_pm_ops callback.
>>
>> FWIW, if platform_pci_power_manageable() returns true, it can probably
>> be assumed that allowing runtime PM by default is okay.  So as a first
>> step, you may want to call that instead of adding a new callback.
>>
> I don't think that's sufficient. Most likely all the broken old systems
> return true for platform_pci_power_manageable(). So yes, most likely
> we'd need a new callback if we want to have the platform ops abstraction.
> But it could be an optional callback, something like: forbid_runtime_pm
> The question is just: is it worth it?
> 
> By the way: pci_set_platform_pm() returns an error if a callback isn't
> set, but no existing caller bothers to check the return code.
> 
>> Thanks,
>>
>> Lukas
>>
> Heiner
> 

This would be the version with the abstraction.

---
 drivers/pci/pci-acpi.c | 6 ++
 drivers/pci/pci.c  | 9 -
 drivers/pci/pci.h  | 5 -
 3 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
index 53502a751..b57a79af7 100644
--- a/drivers/pci/pci-acpi.c
+++ b/drivers/pci/pci-acpi.c
@@ -1108,6 +1108,11 @@ static bool acpi_pci_need_resume(struct pci_dev *dev)
return !!adev->power.flags.dsw_present;
 }
 
+static bool acpi_pci_forbid_runtime_pm(void)
+{
+   return acpi_gbl_FADT.header.revision < 6;
+}
+
 static const struct pci_platform_pm_ops acpi_pci_platform_pm = {
.bridge_d3 = acpi_pci_bridge_d3,
.is_manageable = acpi_pci_power_manageable,
@@ -1117,6 +1122,7 @@ static const struct pci_platform_pm_ops 
acpi_pci_platform_pm = {
.choose_state = acpi_pci_choose_state,
.set_wakeup = acpi_pci_wakeup,
.need_resume = acpi_pci_need_resume,
+   .forbid_runtime_pm = acpi_pci_forbid_runtime_pm,
 };
 
 void acpi_pci_add_bus(struct pci_bus *bus)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index b9fecc25d..3af832b7f 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -982,6 +982,12 @@ static inline bool platform_pci_need_resume(struct pci_dev 
*dev)
return pci_platform_pm ? pci_platform_pm->need_resume(dev) : false;
 }
 
+static inline bool platform_pci_forbid_runtime_pm(void)
+{
+   return pci_platform_pm && pci_platform_pm->forbid_runtime_pm ?
+  pci_platform_pm->forbid_runtime_pm() : false;
+}
+
 static inline bool platform_pci_bridge_d3(struct pci_dev *dev)
 {
if (pci_platform_pm && pci_platform_pm->bridge_d3)
@@ -3024,7 +3030,8 @@ void pci_pm_init(struct pci_dev *dev)
u16 status;
u16 pmc;
 
-   pm_runtime_forbid(&dev->dev);
+   if (platform_pci_forbid_runtime_pm())
+   pm_runtime_forbid(&dev->dev);
pm_runtime_set_active(&dev->dev);
pm_runtime_enable(&dev->dev);
device_enable_async_suspend(&dev->dev);
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 5c5936509..d2d406ee4 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -71,8 +71,10 @@ int pci_bus_error_reset(struct pci_dev *dev);
  *  suspended) needs to be resumed to be configured for system
  *  wakeup.
  *
+ * @forbid_runtime_pm: returns true in case of known issues breaking runtime pm
+ *
  * If given platform is generally capable of power managing PCI devices, all of
- * these callbacks are mandatory.
+ * these callbacks are mandatory (except forbid_runtime_pm).
  */
 struct pci_platform_pm_ops {
bool (*bridge_d3)(struct pci_dev *dev);
@@ -83,6 +85,7 @@ struct pci_platform_pm_ops {
pci_power_t (*choose_state)(struct pci_dev *dev);
int (*set_wakeup)(struct pci_dev *dev, bool enable);
bool (*need_resume)(struct pci_dev *dev);
+   bool (*forbid_runtime_pm)(void);
 };
 
 int pci_set_platform_pm(const struct pci_platform_pm_ops *ops);
-- 
2.29.2

Re: [PATCH] riscv: add BUILTIN_DTB support for MMU-enabled targets

[Vitaly Wool]

On Tue, Dec 29, 2020 at 6:05 AM Anup Patel  wrote:
>
> On Mon, Dec 28, 2020 at 10:08 PM Vitaly Wool  wrote:
> >
> > On Mon, Dec 28, 2020 at 3:10 PM Anup Patel  wrote:
> > >
> > > On Mon, Dec 28, 2020 at 7:05 PM Vitaly Wool  
> > > wrote:
> > > >
> > > > On Mon, Dec 28, 2020 at 12:59 PM Anup Patel  wrote:
> > > > >
> > > > > On Sat, Dec 26, 2020 at 10:03 PM Vitaly Wool 
> > > > >  wrote:
> > > > > >
> > > > > > Sometimes, especially in a production system we may not want to
> > > > > > use a "smart bootloader" like u-boot to load kernel, ramdisk and
> > > > > > device tree from a filesystem on eMMC, but rather load the kernel
> > > > > > from a NAND partition and just run it as soon as we can, and in
> > > > > > this case it is convenient to have device tree compiled into the
> > > > > > kernel binary. Since this case is not limited to MMU-less systems,
> > > > > > let's support it for these which have MMU enabled too.
> > > > > >
> > > > > > Signed-off-by: Vitaly Wool 
> > > > > > ---
> > > > > >  arch/riscv/Kconfig   |  1 -
> > > > > >  arch/riscv/mm/init.c | 12 ++--
> > > > > >  2 files changed, 10 insertions(+), 3 deletions(-)
> > > > > >
> > > > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > > > > > index 2b41f6d8e458..9464b4e3a71a 100644
> > > > > > --- a/arch/riscv/Kconfig
> > > > > > +++ b/arch/riscv/Kconfig
> > > > > > @@ -419,7 +419,6 @@ endmenu
> > > > > >
> > > > > >  config BUILTIN_DTB
> > > > > > def_bool n
> > > > > > -   depends on RISCV_M_MODE
> > > > > > depends on OF
> > > > > >
> > > > > >  menu "Power management options"
> > > > > > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> > > > > > index 87c305c566ac..5d1c7a3ec01c 100644
> > > > > > --- a/arch/riscv/mm/init.c
> > > > > > +++ b/arch/riscv/mm/init.c
> > > > > > @@ -194,12 +194,20 @@ void __init setup_bootmem(void)
> > > > > > setup_initrd();
> > > > > >  #endif /* CONFIG_BLK_DEV_INITRD */
> > > > > >
> > > > > > +   /*
> > > > > > +* If DTB is built in, no need to reserve its memblock.
> > > > > > +* OTOH, initial_boot_params has to be set to properly copy 
> > > > > > DTB
> > > > > > +* before unflattening later on.
> > > > > > +*/
> > > > > > +   if (IS_ENABLED(CONFIG_BUILTIN_DTB))
> > > > > > +   initial_boot_params = __va(dtb_early_pa);
> > > > >
> > > > > Don't assign initial_boot_params directly here because the
> > > > > early_init_dt_scan() will do it.
> > > >
> > > > early_init_dt_scan will set initial_boot_params to dtb_early_va from
> > > > the early mapping which will be gone by the time
> > > > unflatten_and_copy_device_tree() is called.
> > >
> > > That's why we are doing early_init_dt_verify() again for the MMU-enabled
> > > case which already takes care of your concern.
> >
> > I might be out in the woods here but... Do you mean the call to
> > early_init_dt_verify() in setup_arch() which is compiled out
> > completely in the CONFIG_BUILTIN_DTB case?
> > Or is there any other call that I'm overlooking?
>
> Sorry for the confusion, what I meant was that we are calling
> early_init_dt_verify() from setup_arch() for the MMU-enabled
> with built-in DTB disabled case to update "initial_boot_params"
> after the boot CPU has switched from early_pg_dir to swapper_pg_dir.
>
> For MMU-enabled with built-in DTB case, if setup_vm() sets the
> dtb_early_va and dtb_early_pa correctly then early_init_dt_scan()
> called from setup_arch() will automatically set correct value for
> "initial_boot_params".

Oh I think I get it now. You are suggesting to skip the temporary
mapping for DT altogether since it is anyway in the kernel mapping
range, aren't you?
That does make sense indeed, thanks :)

> It is strange that early_init_dt_verify() is being compiled-out for you
> because the early_init_dt_scan() called from setup_arch() also uses
> early_init_dt_verify(). I quickly compiled the NoMMU kernel for K210
> which also uses built-in DTB and I see that early_init_dt_verify()
> is not being compiled-out when built-in DTB is enabled.

I did not say that early_init_dt_verify() is compiled out, it's the
call to it in setup_arch() that is compiled out if BUILTIN_DTB is
selected. However, if I understand you correctly now, it should not
matter if we don't set dtb_early_va to point to the temporary mapping.

Best regards,
   Vitaly
>
> Regards,
> Anup
>
> >
> > Best regards,
> >Vitaly
> >
> > > We use early_init_dt_verify() like most architectures to set the initial 
> > > DTB.
> > >
> > > >
> > > > > The setup_vm() is supposed to setup dtb_early_va and dtb_early_pa
> > > > > for MMU-enabled case so please add a "#ifdef" over there for the
> > > > > built-in DTB case.
> > > > >
> > > > > > +   else
> > > > > > +   memblock_reserve(dtb_early_pa, 
> > > > > > fdt_totalsize(dtb_early_va));
> > > > > > +
> > > > > > /*
> > > > > >  * Avoid using early_init_fdt_reserve_self() since __pa() 
> > > > > >

[PATCH] drm/msm: dsi: Remove redundant null check before clk_prepare_enable/clk_disable_unprepare

[Xu Wang]

Because clk_prepare_enable() and clk_disable_unprepare() already checked
NULL clock parameter, so the additional checks are unnecessary, just
remove them.

Signed-off-by: Xu Wang 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index ab281cba0f08..e7af90f045bf 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -565,13 +565,11 @@ int dsi_link_clk_enable_6g(struct msm_dsi_host *msm_host)
goto pixel_clk_err;
}
 
-   if (msm_host->byte_intf_clk) {
-   ret = clk_prepare_enable(msm_host->byte_intf_clk);
-   if (ret) {
-   pr_err("%s: Failed to enable byte intf clk\n",
-  __func__);
-   goto byte_intf_clk_err;
-   }
+   ret = clk_prepare_enable(msm_host->byte_intf_clk);
+   if (ret) {
+   pr_err("%s: Failed to enable byte intf clk\n",
+  __func__);
+   goto byte_intf_clk_err;
}
 
return 0;
@@ -667,8 +665,7 @@ void dsi_link_clk_disable_6g(struct msm_dsi_host *msm_host)
dev_pm_opp_set_rate(&msm_host->pdev->dev, 0);
clk_disable_unprepare(msm_host->esc_clk);
clk_disable_unprepare(msm_host->pixel_clk);
-   if (msm_host->byte_intf_clk)
-   clk_disable_unprepare(msm_host->byte_intf_clk);
+   clk_disable_unprepare(msm_host->byte_intf_clk);
clk_disable_unprepare(msm_host->byte_clk);
 }
 
-- 
2.17.1

答复: [PATCH] net: remove disc_data_lock in ppp line discipline

[Gaoyan]

Dear all：

Could I get your comments for the updates?  If I can get a reply, it will help 
me a lot . Thanks

https://lkml.org/lkml/2020/12/28/19



***


Original mail -
发件人: gaoyan (RD) 
发送时间: 2020年12月28日 15:16
收件人: pau...@samba.org; da...@davemloft.net; k...@kernel.org
抄送: linux-...@vger.kernel.org; net...@vger.kernel.org; 
linux-kernel@vger.kernel.org; gaoyan (RD) 
主题: [PATCH] net: remove disc_data_lock in ppp line discipline

In tty layer, it use tty->ldisc_sem to proect tty_ldisc_ops.
So I think tty->ldisc_sem can also protect tty->disc_data; For examlpe, When 
cpu A is running ppp_synctty_ioctl that hold the tty->ldisc_sem, at the same 
time  if cpu B calls ppp_synctty_close, it will wait until cpu A release 
tty->ldisc_sem. So I think it is unnecessary to have the disc_data_lock;

cpu A   cpu B
tty_ioctl   tty_reopen
 ->hold tty->ldisc_sem->hold tty->ldisc_sem(write), failed
 ->ld->ops->ioctl ->wait...
 ->release tty->ldisc_sem ->wait...OK,hold tty->ldisc_sem
->tty_ldisc_reinit
  ->tty_ldisc_close
->ld->ops->close

Signed-off-by: Gao Yan 
---
 drivers/net/ppp/ppp_async.c   | 11 ++-
 drivers/net/ppp/ppp_synctty.c | 12 ++--
 2 files changed, 4 insertions(+), 19 deletions(-)

diff --git a/drivers/net/ppp/ppp_async.c b/drivers/net/ppp/ppp_async.c index 
29a0917a8..20b50facd 100644
--- a/drivers/net/ppp/ppp_async.c
+++ b/drivers/net/ppp/ppp_async.c
@@ -127,17 +127,13 @@ static const struct ppp_channel_ops async_ops = {
  * FIXME: this is no longer true. The _close path for the ldisc is
  * now guaranteed to be sane.
  */
-static DEFINE_RWLOCK(disc_data_lock);
 
 static struct asyncppp *ap_get(struct tty_struct *tty)  {
-   struct asyncppp *ap;
+   struct asyncppp *ap = tty->disc_data;
 
-   read_lock(&disc_data_lock);
-   ap = tty->disc_data;
if (ap != NULL)
refcount_inc(&ap->refcnt);
-   read_unlock(&disc_data_lock);
return ap;
 }
 
@@ -214,12 +210,9 @@ ppp_asynctty_open(struct tty_struct *tty)  static void  
ppp_asynctty_close(struct tty_struct *tty)  {
-   struct asyncppp *ap;
+   struct asyncppp *ap = tty->disc_data;
 
-   write_lock_irq(&disc_data_lock);
-   ap = tty->disc_data;
tty->disc_data = NULL;
-   write_unlock_irq(&disc_data_lock);
if (!ap)
return;
 
diff --git a/drivers/net/ppp/ppp_synctty.c b/drivers/net/ppp/ppp_synctty.c 
index 0f338752c..53fb68e29 100644
--- a/drivers/net/ppp/ppp_synctty.c
+++ b/drivers/net/ppp/ppp_synctty.c
@@ -129,17 +129,12 @@ ppp_print_buffer (const char *name, const __u8 *buf, int 
count)
  *
  * FIXME: Fixed in tty_io nowadays.
  */
-static DEFINE_RWLOCK(disc_data_lock);
-
 static struct syncppp *sp_get(struct tty_struct *tty)  {
-   struct syncppp *ap;
+   struct syncppp *ap = tty->disc_data;
 
-   read_lock(&disc_data_lock);
-   ap = tty->disc_data;
if (ap != NULL)
refcount_inc(&ap->refcnt);
-   read_unlock(&disc_data_lock);
return ap;
 }
 
@@ -213,12 +208,9 @@ ppp_sync_open(struct tty_struct *tty)  static void  
ppp_sync_close(struct tty_struct *tty)  {
-   struct syncppp *ap;
+   struct syncppp *ap = tty->disc_data;
 
-   write_lock_irq(&disc_data_lock);
-   ap = tty->disc_data;
tty->disc_data = NULL;
-   write_unlock_irq(&disc_data_lock);
if (!ap)
return;
 
--
2.17.1

Re: Haswell audio no longer working with new Catpt driver (was: sound)

[Lars-Peter Clausen]

On 12/31/20 9:33 AM, Greg Kroah-Hartman wrote:

On Wed, Dec 30, 2020 at 07:10:16PM +0100, Christian Labisch wrote:

Update :

I've just tested the kernel 5.10.4 from ELRepo.
Unfortunately nothing changed - still no sound.

Ah, sad.  Can you run 'git bisect' between 5.9 and 5.10 to determine the
commit that caused the problem?


The problem is that one driver was replaced with another driver. git 
bisect wont really help to narrow down why the new driver does not work.


Christian can you run the alsa-info.sh[1] script on your system and send 
back the result?


You say sound is not working, can you clarify that a bit? Is no sound 
card registered? Is it registered but output stays silent?


- Lars

[1] https://www.alsa-project.org/wiki/AlsaInfo 

Re: [PATCH] mt76: Fix queue ID variable types after mcu queue split

[Lorenzo Bianconi]

> Clang warns in both mt7615 and mt7915:
> 
> drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:271:9: warning: implicit
> conversion from enumeration type 'enum mt76_mcuq_id' to different
> enumeration type 'enum mt76_txq_id' [-Wenum-conversion]
> txq = MT_MCUQ_FWDL;
> ~ ^~~~
> drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:278:9: warning: implicit
> conversion from enumeration type 'enum mt76_mcuq_id' to different
> enumeration type 'enum mt76_txq_id' [-Wenum-conversion]
> txq = MT_MCUQ_WA;
> ~ ^~
> drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:282:9: warning: implicit
> conversion from enumeration type 'enum mt76_mcuq_id' to different
> enumeration type 'enum mt76_txq_id' [-Wenum-conversion]
> txq = MT_MCUQ_WM;
> ~ ^~
> 3 warnings generated.
> 
> drivers/net/wireless/mediatek/mt76/mt7615/mcu.c:238:9: warning: implicit
> conversion from enumeration type 'enum mt76_mcuq_id' to different
> enumeration type 'enum mt76_txq_id' [-Wenum-conversion]
> qid = MT_MCUQ_WM;
> ~ ^~
> drivers/net/wireless/mediatek/mt76/mt7615/mcu.c:240:9: warning: implicit
> conversion from enumeration type 'enum mt76_mcuq_id' to different
> enumeration type 'enum mt76_txq_id' [-Wenum-conversion]
> qid = MT_MCUQ_FWDL;
> ~ ^~~~
> 2 warnings generated.
> 
> Use the proper type for the queue ID variables to fix these warnings.
> Additionally, rename the txq variable in mt7915_mcu_send_message to be
> more neutral like mt7615_mcu_send_message.
> 
> Fixes: e637763b606b ("mt76: move mcu queues to mt76_dev q_mcu array")
> Link: https://github.com/ClangBuiltLinux/linux/issues/1229
> Signed-off-by: Nathan Chancellor 

Acked-by: Lorenzo Bianconi 

> ---
>  drivers/net/wireless/mediatek/mt76/mt7615/mcu.c |  2 +-
>  drivers/net/wireless/mediatek/mt76/mt7915/mcu.c | 10 +-
>  2 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c 
> b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
> index a44b7766dec6..c13547841a4e 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
> @@ -231,7 +231,7 @@ mt7615_mcu_send_message(struct mt76_dev *mdev, struct 
> sk_buff *skb,
>   int cmd, int *seq)
>  {
>   struct mt7615_dev *dev = container_of(mdev, struct mt7615_dev, mt76);
> - enum mt76_txq_id qid;
> + enum mt76_mcuq_id qid;
>  
>   mt7615_mcu_fill_msg(dev, skb, cmd, seq);
>   if (test_bit(MT76_STATE_MCU_RUNNING, &dev->mphy.state))
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c 
> b/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c
> index 5fdd1a6d32ee..e211a2bd4d3c 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c
> @@ -256,7 +256,7 @@ mt7915_mcu_send_message(struct mt76_dev *mdev, struct 
> sk_buff *skb,
>   struct mt7915_dev *dev = container_of(mdev, struct mt7915_dev, mt76);
>   struct mt7915_mcu_txd *mcu_txd;
>   u8 seq, pkt_fmt, qidx;
> - enum mt76_txq_id txq;
> + enum mt76_mcuq_id qid;
>   __le32 *txd;
>   u32 val;
>  
> @@ -268,18 +268,18 @@ mt7915_mcu_send_message(struct mt76_dev *mdev, struct 
> sk_buff *skb,
>   seq = ++dev->mt76.mcu.msg_seq & 0xf;
>  
>   if (cmd == -MCU_CMD_FW_SCATTER) {
> - txq = MT_MCUQ_FWDL;
> + qid = MT_MCUQ_FWDL;
>   goto exit;
>   }
>  
>   mcu_txd = (struct mt7915_mcu_txd *)skb_push(skb, sizeof(*mcu_txd));
>  
>   if (test_bit(MT76_STATE_MCU_RUNNING, &dev->mphy.state)) {
> - txq = MT_MCUQ_WA;
> + qid = MT_MCUQ_WA;
>   qidx = MT_TX_MCU_PORT_RX_Q0;
>   pkt_fmt = MT_TX_TYPE_CMD;
>   } else {
> - txq = MT_MCUQ_WM;
> + qid = MT_MCUQ_WM;
>   qidx = MT_TX_MCU_PORT_RX_Q0;
>   pkt_fmt = MT_TX_TYPE_CMD;
>   }
> @@ -326,7 +326,7 @@ mt7915_mcu_send_message(struct mt76_dev *mdev, struct 
> sk_buff *skb,
>   if (wait_seq)
>   *wait_seq = seq;
>  
> - return mt76_tx_queue_skb_raw(dev, mdev->q_mcu[txq], skb, 0);
> + return mt76_tx_queue_skb_raw(dev, mdev->q_mcu[qid], skb, 0);
>  }
>  
>  static void
> 
> base-commit: 5c8fe583cce542aa0b84adc939ce85293de36e5e
> -- 
> 2.30.0
> 


signature.asc
Description: PGP signature

[PATCH v5 0/2] PCI: Add new Unisoc PCIe driver

[Hongtao Wu]

From: Hongtao Wu 

This series adds PCIe controller driver for Unisoc SoCs.
This controller is based on DesignWare PCIe IP.

Changes from v1:
1) Test this patch on top of Rob Herring's 40 part series of DWC clean-ups:
   https://lore.kernel.org/linux-pci/20200821035420.380495-1-r...@kernel.org/

2) Delete empty function

3) Document property "sprd,pcie-poweron-syscons" and
   'sprd,pcie-poweroff-syscons'

4) Delete runtime suspend/resume function

5) Add COMPILE_TEST which CONFIG_PCIE_SPRD depends on

Changes from v2:
1) Change RC mode to host mode in drivers/pci/controller/dwc/Kconfig

2) Change Signed-off-by from Billows Wu to Hongtao Wu

Changes from v3:
1) Split the property 'sprd,pcie-poweron-syscons' and
   'sprd,pcie-poweroff-syscons' into reset, power domains, phy and so on.

2) Delete the function to get resource 'msi' and 'dbi' which were parsed by the
   DW core.

3) Delete the function 'sprd_pcie_host_init', because the DW core has done it.

Changes from v4:
1) Install 'yamllint' and upgrade dt-schema in order to solve the yamllint and
   dtschema/dtc warnings/errors.

Hongtao Wu (2):
  dt-bindings: PCI: sprd: Document Unisoc PCIe RC host controller
  PCI: sprd: Add support for Unisoc SoCs' PCIe controller

 .../devicetree/bindings/pci/sprd-pcie.yaml |  93 +++
 drivers/pci/controller/dwc/Kconfig |  12 +
 drivers/pci/controller/dwc/Makefile|   1 +
 drivers/pci/controller/dwc/pcie-sprd.c | 293 +
 4 files changed, 399 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/sprd-pcie.yaml
 create mode 100644 drivers/pci/controller/dwc/pcie-sprd.c

--
2.7.4

[PATCH v5 2/2] PCI: sprd: Add support for Unisoc SoCs' PCIe controller

[Hongtao Wu]

From: Hongtao Wu 

This series adds PCIe controller driver for Unisoc SoCs.
This controller is based on DesignWare PCIe IP.

Signed-off-by: Hongtao Wu 
---
 drivers/pci/controller/dwc/Kconfig |  12 ++
 drivers/pci/controller/dwc/Makefile|   1 +
 drivers/pci/controller/dwc/pcie-sprd.c | 293 +
 3 files changed, 306 insertions(+)
 create mode 100644 drivers/pci/controller/dwc/pcie-sprd.c

diff --git a/drivers/pci/controller/dwc/Kconfig 
b/drivers/pci/controller/dwc/Kconfig
index 22c5529..61f0b79 100644
--- a/drivers/pci/controller/dwc/Kconfig
+++ b/drivers/pci/controller/dwc/Kconfig
@@ -318,4 +318,16 @@ config PCIE_AL
  required only for DT-based platforms. ACPI platforms with the
  Annapurna Labs PCIe controller don't need to enable this.

+config PCIE_SPRD
+   tristate "Unisoc PCIe controller - Host Mode"
+   depends on ARCH_SPRD || COMPILE_TEST
+   depends on PCI_MSI_IRQ_DOMAIN
+   select PCIE_DW_HOST
+   help
+ Unisoc PCIe controller uses the DesignWare core. It can be configured
+ as an Endpoint (EP) or a Root complex (RC). In order to enable host
+ mode (the controller works as RC), PCIE_SPRD must be selected.
+ Say Y or M here if you want to PCIe RC controller support on Unisoc
+ SoCs.
+
 endmenu
diff --git a/drivers/pci/controller/dwc/Makefile 
b/drivers/pci/controller/dwc/Makefile
index a751553..eb546e9 100644
--- a/drivers/pci/controller/dwc/Makefile
+++ b/drivers/pci/controller/dwc/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_PCI_MESON) += pci-meson.o
 obj-$(CONFIG_PCIE_TEGRA194) += pcie-tegra194.o
 obj-$(CONFIG_PCIE_UNIPHIER) += pcie-uniphier.o
 obj-$(CONFIG_PCIE_UNIPHIER_EP) += pcie-uniphier-ep.o
+obj-$(CONFIG_PCIE_SPRD) += pcie-sprd.o

 # The following drivers are for devices that use the generic ACPI
 # pci_root.c driver but don't support standard ECAM config access.
diff --git a/drivers/pci/controller/dwc/pcie-sprd.c 
b/drivers/pci/controller/dwc/pcie-sprd.c
new file mode 100644
index 000..27d7231
--- /dev/null
+++ b/drivers/pci/controller/dwc/pcie-sprd.c
@@ -0,0 +1,293 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * PCIe host controller driver for Unisoc SoCs
+ *
+ * Copyright (C) 2020-2021 Unisoc, Inc.
+ *
+ * Author: Hongtao Wu 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "pcie-designware.h"
+
+/* aon apb syscon */
+#define IPA_ACCESS_CFG 0xcd8
+#define  AON_ACCESS_PCIE_ENBIT(1)
+
+/* pmu apb syscon */
+#define SNPS_PCIE3_SLP_CTRL0xac
+#define  PERST_N_ASSERTBIT(1)
+#define  PERST_N_AUTO_EN   BIT(0)
+#define PD_PCIE_CFG_0  0x3e8
+#define  PCIE_FORCE_SHUTDOWN   BIT(25)
+
+#define PCIE_SS_REG_BASE   0xE00
+#define APB_CLKFREQ_TIMEOUT0x4
+#define  BUSERR_EN BIT(12)
+#define  APB_TIMER_DIS BIT(10)
+#define  APB_TIMER_LIMIT   GENMASK(31, 16)
+
+#define PE0_GEN_CTRL_3 0x58
+#define  LTSSM_EN  BIT(0)
+
+struct sprd_pcie_soc_data {
+   u32 syscon_offset;
+};
+
+static const struct sprd_pcie_soc_data ums9520_syscon_data = {
+   .syscon_offset = 0x1000,/* The offset of set/clear register */
+};
+
+struct sprd_pcie {
+   u32 syscon_offset;
+   struct device   *dev;
+   struct dw_pcie  *pci;
+   struct regmap   *aon_map;
+   struct regmap   *pmu_map;
+   const struct sprd_pcie_soc_data *socdata;
+};
+
+enum sprd_pcie_syscon_type {
+   normal_syscon,  /* it's not a set/clear register */
+   set_syscon, /* set a set/clear register */
+   clr_syscon, /* clear a set/clear register */
+};
+
+static void sprd_pcie_buserr_enable(struct dw_pcie *pci)
+{
+   u32 val;
+
+   val = dw_pcie_readl_dbi(pci, PCIE_SS_REG_BASE + APB_CLKFREQ_TIMEOUT);
+   val &= ~APB_TIMER_DIS;
+   val |= BUSERR_EN;
+   val |= APB_TIMER_LIMIT & (0x1f4 << 16);
+   dw_pcie_writel_dbi(pci, PCIE_SS_REG_BASE + APB_CLKFREQ_TIMEOUT, val);
+}
+
+static void sprd_pcie_ltssm_enable(struct dw_pcie *pci, bool enable)
+{
+   u32 val;
+
+   val = dw_pcie_readl_dbi(pci, PCIE_SS_REG_BASE + PE0_GEN_CTRL_3);
+   if (enable)
+   dw_pcie_writel_dbi(pci, PCIE_SS_REG_BASE + PE0_GEN_CTRL_3,
+  val | LTSSM_EN);
+   else
+   dw_pcie_writel_dbi(pci, PCIE_SS_REG_BASE + PE0_GEN_CTRL_3,
+  val & ~LTSSM_EN);
+}
+
+static int sprd_pcie_syscon_set(struct sprd_pcie *ctrl, struct regmap *map,
+   u32 reg, u32 mask, u32 val,
+   enum sprd_pcie_syscon_type type)
+{
+   int ret = 0;
+   u32 read_val;
+   u32 offset = ctrl->syscon_offset;
+   struct device *dev = ctrl->pci->dev;
+
+   /*
+* Each set/clear register has three registers:
+   

[PATCH v5 1/2] dt-bindings: PCI: sprd: Document Unisoc PCIe RC host controller

[Hongtao Wu]

From: Hongtao Wu 

This series adds PCIe bindings for Unisoc SoCs.
This controller is based on DesignWare PCIe IP.

Signed-off-by: Hongtao Wu 
---
 .../devicetree/bindings/pci/sprd-pcie.yaml | 93 ++
 1 file changed, 93 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/sprd-pcie.yaml

diff --git a/Documentation/devicetree/bindings/pci/sprd-pcie.yaml 
b/Documentation/devicetree/bindings/pci/sprd-pcie.yaml
new file mode 100644
index 000..ede06a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/sprd-pcie.yaml
@@ -0,0 +1,93 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pci/sprd-pcie.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SoC PCIe Host Controller Device Tree Bindings
+
+maintainers:
+  - Hongtao Wu 
+
+allOf:
+  - $ref: /schemas/pci/pci-bus.yaml#
+
+properties:
+  compatible:
+items:
+  - const: sprd,ums9520-pcie
+
+  reg:
+minItems: 2
+items:
+  - description: Controller control and status registers.
+  - description: PCIe configuration registers.
+
+  reg-names:
+items:
+  - const: dbi
+  - const: config
+
+  ranges:
+maxItems: 2
+
+  num-lanes:
+maximum: 1
+description: Number of lanes to use for this port.
+
+  interrupts:
+minItems: 1
+description: Builtin MSI controller and PCIe host controller.
+
+  interrupt-names:
+items:
+  - const: msi
+
+  sprd,regmap-aon:
+$ref: '/schemas/types.yaml#/definitions/phandle'
+description:
+  Phandle to the AON system controller node (to access the
+  AON_ACCESS_PCIE_EN register on ums9520).
+  sprd,regmap-pmu:
+$ref: '/schemas/types.yaml#/definitions/phandle'
+description:
+  Phandle to the PMU system controller node (to access the PERST_N_ASSERT
+  register on ums9520).
+
+required:
+  - compatible
+  - reg
+  - reg-names
+  - num-lanes
+  - ranges
+  - interrupts
+  - interrupt-names
+
+additionalProperties: true
+
+examples:
+  - |
+#include 
+
+ipa {
+#address-cells = <2>;
+#size-cells = <2>;
+
+pcie0: pcie@2b10 {
+compatible = "sprd,ums9520-pcie";
+reg = <0x0 0x2b10 0x0 0x2000>,
+  <0x2 0x 0x0 0x2000>;
+reg-names = "dbi", "config";
+#address-cells = <3>;
+#size-cells = <2>;
+device_type = "pci";
+ranges = <0x0100 0x0 0x 0x2 0x2000 0x0 0x0001>,
+ <0x0300 0x0 0x1000 0x2 0x1000 0x1 0xefff>;
+num-lanes = <1>;
+interrupts = ;
+interrupt-names = "msi";
+
+sprd,regmap-aon = <&aon_regs>;
+sprd,regmap-pmu = <&pmu_regs>;
+};
+};
--
2.7.4

5.11-rc1 TTM list corruption

[Borislav Petkov]

Hi folks,

got this when trying to suspend my workstation to disk, it was still
responsive so I could catch the splat:

[22020.334381] [ cut here ]
[22020.339057] list_del corruption. next->prev should be 8b7a9a40, but 
was 8881020bced0
[22020.347764] WARNING: CPU: 12 PID: 13134 at lib/list_debug.c:54 
__list_del_entry_valid+0x8a/0x90
[22020.356397] Modules linked in: fuse essiv authenc nft_counter nf_tables 
libcrc32c nfnetlink loop dm_crypt dm_mod amd64_edac edac_mce_amd kvm_amd 
snd_hda_codec_realtek snd_hda_codec_generic led_class kvm ledtrig_audio 
snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core 
snd_pcm snd_timer irqbypass crct10dif_pclmul snd crc32_pclmul crc32c_intel 
ghash_clmulni_intel pcspkr k10temp soundcore gpio_amdpt gpio_generic 
acpi_cpufreq radeon aesni_intel glue_helper crypto_simd cryptd pinctrl_amd
[22020.400855] CPU: 12 PID: 13134 Comm: hib.sh Not tainted 5.11.0-rc1+ #2
[22020.400857] Hardware name: Micro-Star International Co., Ltd. MS-7B79/X470 
GAMING PRO (MS-7B79), BIOS 1.70 01/23/2019
[22020.400858] RIP: 0010:__list_del_entry_valid+0x8a/0x90
[22020.400861] Code: 46 00 0f 0b 31 c0 c3 48 89 f2 48 89 fe 48 c7 c7 78 30 0f 
82 e8 24 6c 46 00 0f 0b 31 c0 c3 48 c7 c7 b8 30 0f 82 e8 13 6c 46 00 <0f> 0b 31 
c0 c3 cc 48 85 d2 89 f8 74 20 48 8d 0c 16 0f b6 16 48 ff
[22020.400863] RSP: 0018:c90001fbbcf8 EFLAGS: 00010292
[22020.441503] RAX: 0054 RBX: 8b7a9a40 RCX: 
[22020.441505] RDX: 8887fef26600 RSI: 8887fef17450 RDI: 8887fef17450
[22020.441505] RBP: 3f82 R08: 8887fef17450 R09: c90001fbbb38
[22020.441506] R10: 0001 R11: 0001 R12: 
[22020.441507] R13: 0080 R14: 0480 R15: 019b
[22020.441508] FS:  7f51c72f9740() GS:8887fef0() 
knlGS:
[22020.490045] CS:  0010 DS:  ES:  CR0: 80050033
[22020.490046] CR2: 5557afb81018 CR3: 00012099e000 CR4: 003506e0
[22020.490047] Call Trace:
[22020.490048]  ttm_pool_shrink+0x61/0xd0
[22020.508965]  ttm_pool_shrinker_scan+0xa/0x20
[22020.508966]  shrink_slab.part.0.constprop.0+0x1a1/0x330
[22020.508970]  drop_slab_node+0x37/0x50
[22020.522011]  drop_slab+0x33/0x60
[22020.522012]  drop_caches_sysctl_handler+0x70/0x80
[22020.522015]  proc_sys_call_handler+0x140/0x220
[22020.534286]  new_sync_write+0x10b/0x190
[22020.534289]  vfs_write+0x1b7/0x290
[22020.534291]  ksys_write+0x60/0xe0
[22020.544762]  do_syscall_64+0x33/0x40
[22020.544765]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[22020.553320] RIP: 0033:0x7f51c73eaff3
[22020.553322] Code: 8b 15 a1 ee 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb 
b7 0f 1f 00 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 01 00 00 00 0f 05 <48> 3d 00 
f0 ff ff 77 55 c3 0f 1f 40 00 48 83 ec 28 48 89 54 24 18
[22020.553324] RSP: 002b:7ffd0a748ef8 EFLAGS: 0246 ORIG_RAX: 
0001
[22020.553325] RAX: ffda RBX: 0002 RCX: 7f51c73eaff3
[22020.553326] RDX: 0002 RSI: 56039fd0ee70 RDI: 0001
[22020.553327] RBP: 56039fd0ee70 R08: 000a R09: 0001
[22020.553327] R10: 56039fd0e770 R11: 0246 R12: 0002
[22020.611218] R13: 7f51c74bb6a0 R14: 0002 R15: 7f51c74bb8a0
[22020.611220] ---[ end trace f7ea94a6ddb98f71 ]---

-- 
Regards/Gruss,
Boris.

https://people.kernel.org/tglx/notes-about-netiquette

Re: [PATCH] sound: pci: hda: add a new hda codec

[Takashi Iwai]

On Tue, 29 Dec 2020 04:52:26 +0100,
bo@senarytech.com wrote:
> 
> From: bo liu 
> 
> The current kernel does not support the cx11970 codec chip.
> Add a codec configuration item to kernel.
> 
> Signed-off-by: bo liu 

Thanks, applied with a minor coding style fix now.


Takashi

Re: [PATCH 1/2] ASoC: SOF: Intel: hda: Modify existing helper to disable WAKEEN

[Takashi Iwai]

On Tue, 29 Dec 2020 14:38:14 +0100,
Kai-Heng Feng wrote:
> 
> Modify hda_codec_jack_wake_enable() to also support disable WAKEEN.
> This is a preparation for next patch.
> 
> No functional change intended.

Maybe it's better to mention that this patch moves the WAKEEN
disablement call out of hda_codec_jack_check() into
hda_codec_jack_wake_enable(), too.


thanks,

Takashi

> 
> Signed-off-by: Kai-Heng Feng 
> ---
>  sound/soc/sof/intel/hda-codec.c | 16 +++-
>  sound/soc/sof/intel/hda-dsp.c   |  6 --
>  sound/soc/sof/intel/hda.h   |  2 +-
>  3 files changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/sound/soc/sof/intel/hda-codec.c b/sound/soc/sof/intel/hda-codec.c
> index 6875fa570c2c..bc9ac4abdab5 100644
> --- a/sound/soc/sof/intel/hda-codec.c
> +++ b/sound/soc/sof/intel/hda-codec.c
> @@ -63,16 +63,18 @@ static int hda_codec_load_module(struct hda_codec *codec)
>  }
>  
>  /* enable controller wake up event for all codecs with jack connectors */
> -void hda_codec_jack_wake_enable(struct snd_sof_dev *sdev)
> +void hda_codec_jack_wake_enable(struct snd_sof_dev *sdev, bool enable)
>  {
>   struct hda_bus *hbus = sof_to_hbus(sdev);
>   struct hdac_bus *bus = sof_to_bus(sdev);
>   struct hda_codec *codec;
>   unsigned int mask = 0;
>  
> - list_for_each_codec(codec, hbus)
> - if (codec->jacktbl.used)
> - mask |= BIT(codec->core.addr);
> + if (enable) {
> + list_for_each_codec(codec, hbus)
> + if (codec->jacktbl.used)
> + mask |= BIT(codec->core.addr);
> + }
>  
>   snd_hdac_chip_updatew(bus, WAKEEN, STATESTS_INT_MASK, mask);
>  }
> @@ -81,12 +83,8 @@ void hda_codec_jack_wake_enable(struct snd_sof_dev *sdev)
>  void hda_codec_jack_check(struct snd_sof_dev *sdev)
>  {
>   struct hda_bus *hbus = sof_to_hbus(sdev);
> - struct hdac_bus *bus = sof_to_bus(sdev);
>   struct hda_codec *codec;
>  
> - /* disable controller Wake Up event*/
> - snd_hdac_chip_updatew(bus, WAKEEN, STATESTS_INT_MASK, 0);
> -
>   list_for_each_codec(codec, hbus)
>   /*
>* Wake up all jack-detecting codecs regardless whether an event
> @@ -97,7 +95,7 @@ void hda_codec_jack_check(struct snd_sof_dev *sdev)
> codec->jackpoll_interval);
>  }
>  #else
> -void hda_codec_jack_wake_enable(struct snd_sof_dev *sdev) {}
> +void hda_codec_jack_wake_enable(struct snd_sof_dev *sdev, bool enable) {}
>  void hda_codec_jack_check(struct snd_sof_dev *sdev) {}
>  #endif /* CONFIG_SND_SOC_SOF_HDA_AUDIO_CODEC */
>  EXPORT_SYMBOL_NS(hda_codec_jack_wake_enable, SND_SOC_SOF_HDA_AUDIO_CODEC);
> diff --git a/sound/soc/sof/intel/hda-dsp.c b/sound/soc/sof/intel/hda-dsp.c
> index 2b001151fe37..7d00107cf3b2 100644
> --- a/sound/soc/sof/intel/hda-dsp.c
> +++ b/sound/soc/sof/intel/hda-dsp.c
> @@ -617,7 +617,7 @@ static int hda_suspend(struct snd_sof_dev *sdev, bool 
> runtime_suspend)
>  
>  #if IS_ENABLED(CONFIG_SND_SOC_SOF_HDA)
>   if (runtime_suspend)
> - hda_codec_jack_wake_enable(sdev);
> + hda_codec_jack_wake_enable(sdev, true);
>  
>   /* power down all hda link */
>   snd_hdac_ext_bus_link_power_down_all(bus);
> @@ -683,8 +683,10 @@ static int hda_resume(struct snd_sof_dev *sdev, bool 
> runtime_resume)
>  
>  #if IS_ENABLED(CONFIG_SND_SOC_SOF_HDA)
>   /* check jack status */
> - if (runtime_resume)
> + if (runtime_resume) {
> + hda_codec_jack_wake_enable(sdev, false);
>   hda_codec_jack_check(sdev);
> + }
>  
>   /* turn off the links that were off before suspend */
>   list_for_each_entry(hlink, &bus->hlink_list, list) {
> diff --git a/sound/soc/sof/intel/hda.h b/sound/soc/sof/intel/hda.h
> index 9ec8ae0fd649..a3b6f3e9121c 100644
> --- a/sound/soc/sof/intel/hda.h
> +++ b/sound/soc/sof/intel/hda.h
> @@ -650,7 +650,7 @@ void sof_hda_bus_init(struct hdac_bus *bus, struct device 
> *dev);
>   */
>  void hda_codec_probe_bus(struct snd_sof_dev *sdev,
>bool hda_codec_use_common_hdmi);
> -void hda_codec_jack_wake_enable(struct snd_sof_dev *sdev);
> +void hda_codec_jack_wake_enable(struct snd_sof_dev *sdev, bool enable);
>  void hda_codec_jack_check(struct snd_sof_dev *sdev);
>  
>  #endif /* CONFIG_SND_SOC_SOF_HDA */
> -- 
> 2.29.2
> 

Re: [PATCH 2/2] ASoC: SOF: Intel: hda: Avoid checking jack on system suspend

[Takashi Iwai]

On Tue, 29 Dec 2020 14:38:15 +0100,
Kai-Heng Feng wrote:
> 
> System takes a very long time to suspend after commit 215a22ed31a1
> ("ALSA: hda: Refactor codec PM to use direct-complete optimization"):
> [   90.065964] PM: suspend entry (s2idle)
> [   90.067337] Filesystems sync: 0.001 seconds
> [   90.185758] Freezing user space processes ... (elapsed 0.002 seconds) done.
> [   90.188713] OOM killer disabled.
> [   90.188714] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) 
> done.
> [   90.190024] printk: Suspending console(s) (use no_console_suspend to debug)
> [   90.904912] intel_pch_thermal :00:12.0: CPU-PCH is cool [49C], 
> continue to suspend
> [  321.262505] snd_hda_codec_realtek ehdaudio0D0: Unable to sync register 
> 0x2b8000. -5
> [  328.426919] snd_hda_codec_realtek ehdaudio0D0: Unable to sync register 
> 0x2b8000. -5
> [  329.490933] ACPI: EC: interrupt blocked
> 
> That commit keeps codec suspended during the system suspend. However,
> SOF driver's runtime resume, which is for system suspend, calls
> hda_codec_jack_check() and schedules jackpoll_work. The jackpoll
> work uses snd_hda_power_up_pm() which tries to resume the codec in
> system suspend path, hence blocking the suspend process.
> 
> So only check jack status if it's not in system PM process.

After your previous patch set, the legacy HDA does queue the
jackpoll_work only if jackpoll_interval is set.  I suppose rather the
same rule would be applied?


thanks,

Takashi

> 
> Fixes: 215a22ed31a1 ("ALSA: hda: Refactor codec PM to use direct-complete 
> optimization")
> Signed-off-by: Kai-Heng Feng 
> ---
>  sound/soc/sof/intel/hda-dsp.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/sound/soc/sof/intel/hda-dsp.c b/sound/soc/sof/intel/hda-dsp.c
> index 7d00107cf3b2..1c5e05b88a90 100644
> --- a/sound/soc/sof/intel/hda-dsp.c
> +++ b/sound/soc/sof/intel/hda-dsp.c
> @@ -685,7 +685,8 @@ static int hda_resume(struct snd_sof_dev *sdev, bool 
> runtime_resume)
>   /* check jack status */
>   if (runtime_resume) {
>   hda_codec_jack_wake_enable(sdev, false);
> - hda_codec_jack_check(sdev);
> + if (sdev->system_suspend_target == SOF_SUSPEND_NONE)
> + hda_codec_jack_check(sdev);
>   }
>  
>   /* turn off the links that were off before suspend */
> -- 
> 2.29.2
> 

Re: [PATCH] mtd: rawnand: qcom: update last code word register

[Manivannan Sadhasivam]

On Thu, Dec 17, 2020 at 07:32:56PM +0530, Md Sadre Alam wrote:
> From QPIC version 2.0 onwards new register got added to
> read last codeword. This change will update the same.
> 
> For first three code word READ_LOCATION_n register will be
> use.For last code wrod READ_LOCATION_LAST_CW_n register will be
> use.
> 
> Signed-off-by: Md Sadre Alam 
> ---
>  drivers/mtd/nand/raw/qcom_nandc.c | 79 
> +--
>  1 file changed, 67 insertions(+), 12 deletions(-)
> 
> diff --git a/drivers/mtd/nand/raw/qcom_nandc.c 
> b/drivers/mtd/nand/raw/qcom_nandc.c
> index 667e4bf..eaef51d 100644
> --- a/drivers/mtd/nand/raw/qcom_nandc.c
> +++ b/drivers/mtd/nand/raw/qcom_nandc.c
> @@ -48,6 +48,10 @@
>  #define  NAND_READ_LOCATION_10xf24
>  #define  NAND_READ_LOCATION_20xf28
>  #define  NAND_READ_LOCATION_30xf2c
> +#define NAND_READ_LOCATION_LAST_CW_00xf40
> +#define NAND_READ_LOCATION_LAST_CW_10xf44
> +#define NAND_READ_LOCATION_LAST_CW_20xf48
> +#define NAND_READ_LOCATION_LAST_CW_30xf4c

Please keep the alignment as before.

>  
>  /* dummy register offsets, used by write_reg_dma */
>  #define  NAND_DEV_CMD1_RESTORE   0xdead
> @@ -187,6 +191,12 @@ nandc_set_reg(nandc, NAND_READ_LOCATION_##reg,   
> \
> ((size) << READ_LOCATION_SIZE) |  \
> ((is_last) << READ_LOCATION_LAST))
>  
> +#define nandc_set_read_loc_last(nandc, reg, offset, size, is_last)   \
> +nandc_set_reg(nandc, NAND_READ_LOCATION_LAST_CW_##reg,   
> \
> +   ((offset) << READ_LOCATION_OFFSET) |  \
> +   ((size) << READ_LOCATION_SIZE) |  \
> +   ((is_last) << READ_LOCATION_LAST))
> +
>  /*
>   * Returns the actual register address for all NAND_DEV_ registers
>   * (i.e. NAND_DEV_CMD0, NAND_DEV_CMD1, NAND_DEV_CMD2 and NAND_DEV_CMD_VLD)
> @@ -316,6 +326,10 @@ struct nandc_regs {
>   __le32 read_location1;
>   __le32 read_location2;
>   __le32 read_location3;
> + __le32 read_location_last0;
> + __le32 read_location_last1;
> + __le32 read_location_last2;
> + __le32 read_location_last3;
>  
>   __le32 erased_cw_detect_cfg_clr;
>   __le32 erased_cw_detect_cfg_set;
> @@ -644,6 +658,14 @@ static __le32 *offset_to_nandc_reg(struct nandc_regs 
> *regs, int offset)
>   return ®s->read_location2;
>   case NAND_READ_LOCATION_3:
>   return ®s->read_location3;
> + case NAND_READ_LOCATION_LAST_CW_0:
> + return ®s->read_location_last0;
> + case NAND_READ_LOCATION_LAST_CW_1:
> + return ®s->read_location_last1;
> + case NAND_READ_LOCATION_LAST_CW_2:
> + return ®s->read_location_last2;
> + case NAND_READ_LOCATION_LAST_CW_3:
> + return ®s->read_location_last3;
>   default:
>   return NULL;
>   }
> @@ -719,9 +741,13 @@ static void update_rw_regs(struct qcom_nand_host *host, 
> int num_cw, bool read)
>   nandc_set_reg(nandc, NAND_READ_STATUS, host->clrreadstatus);
>   nandc_set_reg(nandc, NAND_EXEC_CMD, 1);
>  
> - if (read)
> + if (read) {
> + if (nandc->props->qpic_v2)
> + nandc_set_read_loc_last(nandc, 0, 0, host->use_ecc ?
> + host->cw_data : host->cw_size, 1);

Forgot to add else? Otherwise both NAND_READ_LOCATION_n and 
NAND_READ_LOCATION_LAST_CW_n
will be used.

>   nandc_set_read_loc(nandc, 0, 0, host->use_ecc ?
>  host->cw_data : host->cw_size, 1);
> + }
>  }
>  
>  /*
> @@ -1096,9 +1122,13 @@ static void config_nand_page_read(struct 
> qcom_nand_controller *nandc)
>  static void
>  config_nand_cw_read(struct qcom_nand_controller *nandc, bool use_ecc)
>  {
> - if (nandc->props->is_bam)
> + if (nandc->props->is_bam) {
> + if (nandc->props->qpic_v2)
> + write_reg_dma(nandc, NAND_READ_LOCATION_LAST_CW_0,
> +   4, NAND_BAM_NEXT_SGL);
>   write_reg_dma(nandc, NAND_READ_LOCATION_0, 4,
> NAND_BAM_NEXT_SGL);

Don't you need to modify the number of registers to write? It can't be 4 all the
time if NAND_READ_LOCATION_LAST_CW_0 is used.

> + }
>  
>   write_reg_dma(nandc, NAND_FLASH_CMD, 1, NAND_BAM_NEXT_SGL);
>   write_reg_dma(nandc, NAND_EXEC_CMD, 1, NAND_BAM_NEXT_SGL);
> @@ -1633,16 +1663,28 @@ qcom_nandc_read_cw_raw(struct mtd_info *mtd, struct 
> nand_chip *chip,
>   }
>  
>   if (nandc->props->is_bam) {
> - nandc_set_read_loc(nandc, 0, read_loc, data_size1, 0);
> + if (nandc->props->qpic_v2 && cw == (ecc->steps - 1))
> + nandc_set_read_loc_last(nandc, 0, read_loc, data_size1, 
> 0);
> + else
> + nandc_set_read_loc(nandc, 0, read_loc, data_size1, 0);

IIUC nandc_set_read_lo

[tip: x86/microcode] x86/microcode: Make microcode_init() static

[tip-bot2 for Borislav Petkov]

The following commit has been merged into the x86/microcode branch of tip:

Commit-ID: c769dcd423785703f17ca0a99925a7f9d84b3cbc
Gitweb:
https://git.kernel.org/tip/c769dcd423785703f17ca0a99925a7f9d84b3cbc
Author:Borislav Petkov 
AuthorDate:Wed, 30 Dec 2020 11:20:25 +01:00
Committer: Borislav Petkov 
CommitterDate: Thu, 31 Dec 2020 11:44:00 +01:00

x86/microcode: Make microcode_init() static

No functional changes.

Signed-off-by: Borislav Petkov 
Link: https://lkml.kernel.org/r/20201230122147.26938-1...@alien8.de
---
 arch/x86/include/asm/microcode.h | 2 --
 arch/x86/kernel/cpu/microcode/core.c | 2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/microcode.h b/arch/x86/include/asm/microcode.h
index 2b7cc53..ab45a22 100644
--- a/arch/x86/include/asm/microcode.h
+++ b/arch/x86/include/asm/microcode.h
@@ -127,14 +127,12 @@ static inline unsigned int x86_cpuid_family(void)
 }
 
 #ifdef CONFIG_MICROCODE
-int __init microcode_init(void);
 extern void __init load_ucode_bsp(void);
 extern void load_ucode_ap(void);
 void reload_early_microcode(void);
 extern bool get_builtin_firmware(struct cpio_data *cd, const char *name);
 extern bool initrd_gone;
 #else
-static inline int __init microcode_init(void)  { return 0; };
 static inline void __init load_ucode_bsp(void) { }
 static inline void load_ucode_ap(void) { }
 static inline void reload_early_microcode(void){ }
diff --git a/arch/x86/kernel/cpu/microcode/core.c 
b/arch/x86/kernel/cpu/microcode/core.c
index ec6f041..b935e1b 100644
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -830,7 +830,7 @@ static const struct attribute_group 
cpu_root_microcode_group = {
.attrs = cpu_root_microcode_attrs,
 };
 
-int __init microcode_init(void)
+static int __init microcode_init(void)
 {
struct cpuinfo_x86 *c = &boot_cpu_data;
int error;

Re: [PATCH] ALSA: hda/realtek: Add mute LED quirk for more HP laptops

[Takashi Iwai]

On Tue, 29 Dec 2020 15:38:56 +0100,
Manuel Jiménez wrote:
> 
> HP Pavilion 13-bb (SSID 103c:87c8) needs the same
> quirk as other models with ALC287.
> 
> Signed-off-by: Manuel Jiménez 

Applied now.  Thanks.


Takashi

Re: [PATCH] ALSA: hda/realtek: Enable mute and micmute LED on HP EliteBook 850 G7

[Takashi Iwai]

On Wed, 30 Dec 2020 13:56:35 +0100,
Kai-Heng Feng wrote:
> 
> HP EliteBook 850 G7 uses the same GPIO pins as ALC285_FIXUP_HP_GPIO_LED
> to enable mute and micmute LED. So apply the quirk to enable the LEDs.
> 
> Signed-off-by: Kai-Heng Feng 

Thanks, applied now.


Takashi

Re: [PATCH v2 2/2] arm64: dts: meson: add initial Beelink GS-King-X device-tree

[Neil Armstrong]

On 30/12/2020 11:37, Christian Hewitt wrote:
> The Shenzen AZW (Beelink) GS-King-X is based on the Amlogic W400 reference
> board with an S922X-H chip.
> 
> - 4GB LPDDR4 RAM
> - 64GB eMMC storage
> - 10/100/1000 Base-T Ethernet
> - AP6356S Wireless (802.11 a/b/g/n/ac, BT 4.1)
> - HDMI 2.1 video
> - S/PDIF optical output
> - 2x ESS9018 audio DACs
> - 4x Ricor RT6862 audio amps
> - Analogue headphone output
> - 1x USB 2.0 OTG port
> - 3x USB 3.0 ports
> - IR receiver
> - 1x micro SD card slot (internal)
> - USB SATA controller with 2x 3.5" drive bays
> - 1x Power on/off button
> 
> Signed-off-by: Christian Hewitt 
> ---
>  arch/arm64/boot/dts/amlogic/Makefile  |   1 +
>  .../boot/dts/amlogic/meson-g12b-gsking-x.dts  | 133 ++
>  2 files changed, 134 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/amlogic/meson-g12b-gsking-x.dts
> 
> diff --git a/arch/arm64/boot/dts/amlogic/Makefile 
> b/arch/arm64/boot/dts/amlogic/Makefile
> index ced03946314f..dce41cd3f347 100644
> --- a/arch/arm64/boot/dts/amlogic/Makefile
> +++ b/arch/arm64/boot/dts/amlogic/Makefile
> @@ -3,6 +3,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-axg-s400.dtb
>  dtb-$(CONFIG_ARCH_MESON) += meson-g12a-sei510.dtb
>  dtb-$(CONFIG_ARCH_MESON) += meson-g12a-u200.dtb
>  dtb-$(CONFIG_ARCH_MESON) += meson-g12a-x96-max.dtb
> +dtb-$(CONFIG_ARCH_MESON) += meson-g12b-gsking-x.dtb
>  dtb-$(CONFIG_ARCH_MESON) += meson-g12b-gtking.dtb
>  dtb-$(CONFIG_ARCH_MESON) += meson-g12b-gtking-pro.dtb
>  dtb-$(CONFIG_ARCH_MESON) += meson-g12b-a311d-khadas-vim3.dtb
> diff --git a/arch/arm64/boot/dts/amlogic/meson-g12b-gsking-x.dts 
> b/arch/arm64/boot/dts/amlogic/meson-g12b-gsking-x.dts
> new file mode 100644
> index ..c9d9dcb0cd65
> --- /dev/null
> +++ b/arch/arm64/boot/dts/amlogic/meson-g12b-gsking-x.dts
> @@ -0,0 +1,133 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Copyright (c) 2019 BayLibre, SAS
> + * Author: Neil Armstrong 
> + * Copyright (c) 2019 Christian Hewitt 
> + */
> +
> +/dts-v1/;
> +
> +#include "meson-g12b-w400.dtsi"
> +#include 
> +#include 
> +
> +/ {
> + compatible = "azw,gsking-x", "amlogic,g12b";
> + model = "Beelink GS-King X";
> +
> + aliases {
> + rtc0 = &rtc;
> + rtc1 = &vrtc;
> + };
> +
> + gpio-keys-polled {
> + compatible = "gpio-keys-polled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + poll-interval = <100>;
> +
> + power-button {
> + label = "power";
> + linux,code = ;
> + gpios = <&gpio_ao GPIOAO_3 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + sound {
> + compatible = "amlogic,axg-sound-card";
> + model = "G12B-GSKING-X";
> + audio-aux-devs = <&tdmout_a>;
> + audio-routing = "TDMOUT_A IN 0", "FRDDR_A OUT 1",
> + "TDMOUT_A IN 1", "FRDDR_B OUT 1",
> + "TDMOUT_A IN 2", "FRDDR_C OUT 1",
> + "TDM_A Playback", "TDMOUT_A OUT";
> +
> + assigned-clocks = <&clkc CLKID_MPLL2>,
> +   <&clkc CLKID_MPLL0>,
> +   <&clkc CLKID_MPLL1>;
> + assigned-clock-parents = <0>, <0>, <0>;
> + assigned-clock-rates = <294912000>,
> +<270950400>,
> +<393216000>;
> + status = "okay";
> +
> + dai-link-0 {
> + sound-dai = <&frddr_a>;
> + };
> +
> + dai-link-1 {
> + sound-dai = <&frddr_b>;
> + };
> +
> + dai-link-2 {
> + sound-dai = <&frddr_c>;
> + };
> +
> + /* 8ch hdmi interface */
> + dai-link-3 {
> + sound-dai = <&tdmif_a>;
> + dai-format = "i2s";
> + dai-tdm-slot-tx-mask-0 = <1 1>;
> + dai-tdm-slot-tx-mask-1 = <1 1>;
> + dai-tdm-slot-tx-mask-2 = <1 1>;
> + dai-tdm-slot-tx-mask-3 = <1 1>;
> + mclk-fs = <256>;
> +
> + codec {
> + sound-dai = <&tohdmitx TOHDMITX_I2S_IN_A>;
> + };
> + };
> +
> + dai-link-4 {
> + sound-dai = <&tohdmitx TOHDMITX_I2S_OUT>;
> +
> + codec {
> + sound-dai = <&hdmi_tx>;
> + };
> + };
> + };
> +};
> +
> +&arb {
> + status = "okay";
> +};
> +
> +&clkc_audio {
> + status = "okay";
> +};
> +
> +&frddr_a {
> + status = "okay";
> +};
> +
> +&frddr_b {
> + status = "okay";
> +};
> +
> +&frddr_c {
> + status = "okay";
> +};
> +
> +&i2c3 {
> + status = "okay";
> + pinctrl-0 = <&i2c3_sda_a_pins>, <&i2c3_sc

Re: Haswell audio no longer working with new Catpt driver (was: sound)

[Christian Labisch]

Hi Lars-Peter,

Additional information to what I've sent you already before :
I found out that sound works with headphones (built-in audio)
But sound still does not work with speakers (built-in-audio).

Regards,
Christian

Christian Labisch
Red Hat Accelerator
clnetbox.blogspot.com
access.redhat.com/community
access.redhat.com/accelerators


On Thu, 2020-12-31 at 11:04 +0100, Lars-Peter Clausen wrote:
> On 12/31/20 9:33 AM, Greg Kroah-Hartman wrote:
> > On Wed, Dec 30, 2020 at 07:10:16PM +0100, Christian Labisch wrote:
> > > Update :
> > > 
> > > I've just tested the kernel 5.10.4 from ELRepo.
> > > Unfortunately nothing changed - still no sound.
> > Ah, sad.  Can you run 'git bisect' between 5.9 and 5.10 to determine the
> > commit that caused the problem?
> 
> The problem is that one driver was replaced with another driver. git 
> bisect wont really help to narrow down why the new driver does not work.
> 
> Christian can you run the alsa-info.sh[1] script on your system and send 
> back the result?
> 
> You say sound is not working, can you clarify that a bit? Is no sound 
> card registered? Is it registered but output stays silent?
> 
> - Lars
> 
> [1] https://www.alsa-project.org/wiki/AlsaInfo 
> 
> 
> 

Re: Haswell audio no longer working with new Catpt driver

[Amadeusz Sławiński]

On 12/31/2020 11:50 AM, Christian Labisch wrote:

Hi Lars-Peter,

Thank you, please find attached the requested information from both kernels.
I freshly installed the fedora kernel 5.10.4 to give you the latest results.

Regards,
Christian

Christian Labisch
Red Hat Accelerator
clnetbox.blogspot.com
access.redhat.com/community
access.redhat.com/accelerators


On Thu, 2020-12-31 at 11:04 +0100, Lars-Peter Clausen wrote:

On 12/31/20 9:33 AM, Greg Kroah-Hartman wrote:

On Wed, Dec 30, 2020 at 07:10:16PM +0100, Christian Labisch wrote:

Update :

I've just tested the kernel 5.10.4 from ELRepo.
Unfortunately nothing changed - still no sound.

Ah, sad.  Can you run 'git bisect' between 5.9 and 5.10 to determine the
commit that caused the problem?


The problem is that one driver was replaced with another driver. git
bisect wont really help to narrow down why the new driver does not work.

Christian can you run the alsa-info.sh[1] script on your system and send
back the result?

You say sound is not working, can you clarify that a bit? Is no sound
card registered? Is it registered but output stays silent?

- Lars

[1] https://www.alsa-project.org/wiki/AlsaInfo





Hi,

from reading provided files it seems that you use snd_intel_hda driver, 
it should be possible to git bisect it between 5.9 and 5.10 as it wasn't 
replaced.


Catpt driver is used on machines using DSP.

Amadeusz

Re: Haswell audio no longer working with new Catpt driver

[Christian Labisch]

Thanks Amadeusz,

Now, who has to do what ?
I assume many users will be affected !

Regards,
Christian

On Thu, 2020-12-31 at 12:20 +0100, Amadeusz Sławiński wrote:
> On 12/31/2020 11:50 AM, Christian Labisch wrote:
> > Hi Lars-Peter,
> > 
> > Thank you, please find attached the requested information from both kernels.
> > I freshly installed the fedora kernel 5.10.4 to give you the latest results.
> > 
> > Regards,
> > Christian
> > 
> > Christian Labisch
> > Red Hat Accelerator
> > clnetbox.blogspot.com
> > access.redhat.com/community
> > access.redhat.com/accelerators
> > 
> > 
> > On Thu, 2020-12-31 at 11:04 +0100, Lars-Peter Clausen wrote:
> > > On 12/31/20 9:33 AM, Greg Kroah-Hartman wrote:
> > > > On Wed, Dec 30, 2020 at 07:10:16PM +0100, Christian Labisch wrote:
> > > > > Update :
> > > > > 
> > > > > I've just tested the kernel 5.10.4 from ELRepo.
> > > > > Unfortunately nothing changed - still no sound.
> > > > Ah, sad.  Can you run 'git bisect' between 5.9 and 5.10 to determine the
> > > > commit that caused the problem?
> > > 
> > > The problem is that one driver was replaced with another driver. git
> > > bisect wont really help to narrow down why the new driver does not work.
> > > 
> > > Christian can you run the alsa-info.sh[1] script on your system and send
> > > back the result?
> > > 
> > > You say sound is not working, can you clarify that a bit? Is no sound
> > > card registered? Is it registered but output stays silent?
> > > 
> > > - Lars
> > > 
> > > [1] https://www.alsa-project.org/wiki/AlsaInfo
> > > 
> > > 
> > > 
> 
> Hi,
> 
> from reading provided files it seems that you use snd_intel_hda driver, 
> it should be possible to git bisect it between 5.9 and 5.10 as it wasn't 
> replaced.
> 
> Catpt driver is used on machines using DSP.
> 
> Amadeusz

[PATCH] ACPI: add stub acpi_create_platform_device() for !CONFIG_ACPI

[Shawn Guo]

It adds a stub acpi_create_platform_device() for !CONFIG_ACPI build, so
that caller doesn't have to deal with !CONFIG_ACPI build issue.

Reported-by: kernel test robot 
Signed-off-by: Shawn Guo 
---
This fixes an build issue reported by kernel test robot as below.

https://lore.kernel.org/linux-arm-msm/20201230124925.19260-1-shawn@linaro.org/T/#u

 include/linux/acpi.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 2630c2e953f7..053bf05fb1f7 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -885,6 +885,13 @@ static inline int acpi_device_modalias(struct device *dev,
return -ENODEV;
 }
 
+static inline struct platform_device *
+acpi_create_platform_device(struct acpi_device *adev,
+   struct property_entry *properties)
+{
+   return NULL;
+}
+
 static inline bool acpi_dma_supported(struct acpi_device *adev)
 {
return false;
-- 
2.17.1

Re: [PATCH] xfs: Wake CIL push waiters more reliably

[Donald Buczek]

On 30.12.20 23:16, Dave Chinner wrote:

On Wed, Dec 30, 2020 at 12:56:27AM +0100, Donald Buczek wrote:

Threads, which committed items to the CIL, wait in the xc_push_wait
waitqueue when used_space in the push context goes over a limit. These
threads need to be woken when the CIL is pushed.

The CIL push worker tries to avoid the overhead of calling wake_all()
when there are no waiters waiting. It does so by checking the same
condition which caused the waits to happen. This, however, is
unreliable, because ctx->space_used can actually decrease when items are
recommitted.


When does this happen?

Do you have tracing showing the operation where the relogged item
has actually gotten smaller? By definition, relogging in the CIL
should only grow the size of the object in the CIL because it must
relog all the existing changes on top of the new changed being made
to the object. Hence the CIL reservation should only ever grow.


I have (very ugly printk based) log (see below), but it only shows, that it 
happened (space_used decreasing), not what caused it.

I only browsed the ( xfs_*_item.c ) code and got the impression that the size 
of a log item is rather dynamic (e.g. number of extends in an inode, extended 
attributes in an inode, continuity of chunks in a buffer) and wasn't surprised 
that a relogged item might need less space from time to time.


IOWs, returning negative lengths from the formatting code is
unexpected and probably a bug and requires further investigation,
not papering over the occurrence with broadcast wakeups...


One could argue that the code is more robust after the change, because it wakes 
up every thread which is waiting on the next push to happen when the next push 
is happening without making assumption of why these threads are waiting by 
duplicating code from that waiters side. The proposed waitqueue_active() is 
inlined to two instructions and avoids the call overhead if there are no 
waiters as well.

But, of course, if the size is not expected to decrease, this discrepancy must 
be clarified anyway. I am sure, I can find out the exact circumstances, this 
does happen. I will follow up on this.

Happy New Year!

  Donald

Log extract following



+++ b/fs/xfs/xfs_log_cil.c
@@ -17,6 +17,8 @@
 #include "xfs_log_priv.h"
 #include "xfs_trace.h"
 
+#include 

+
 struct workqueue_struct *xfs_discard_wq;
 
 /*

@@ -670,8 +672,25 @@ xlog_cil_push_work(
/*
 * Wake up any background push waiters now this context is being pushed.
 */
-   if (ctx->space_used >= XLOG_CIL_BLOCKING_SPACE_LIMIT(log))
+   if (ctx->space_used >= XLOG_CIL_BLOCKING_SPACE_LIMIT(log)) {
wake_up_all(&cil->xc_push_wait);
+   pr_warn("XXX wakecil %p ctx %p  ctx->space_used=%d >= %d, 
push_seq=%lld, ctx->sequence=%lld\n",
+   cil, ctx,
+   ctx->space_used,
+   XLOG_CIL_BLOCKING_SPACE_LIMIT(log),
+   cil->xc_push_seq,
+   ctx->sequence);
+   } else {
+   pr_warn("XXX no wake cil %p ctx %p ctx->space_used=%d < %d, 
push_seq=%lld, ctx->sequence=%lld\n",
+   cil, ctx,
+   ctx->space_used,
+   XLOG_CIL_BLOCKING_SPACE_LIMIT(log),
+   cil->xc_push_seq,
+   ctx->sequence);
+   if (waitqueue_active(&cil->xc_push_wait)) {
+   pr_warn("XXX xc_push_wait ACTIVE!\n");
+   }
+   }
 
/*

 * Check if we've anything to push. If there is nothing, then we don't
@@ -918,6 +937,11 @@ xlog_cil_push_background(
spin_lock(&cil->xc_push_lock);
if (cil->xc_push_seq < cil->xc_current_sequence) {
cil->xc_push_seq = cil->xc_current_sequence;
+   pr_warn("XXX trigger cil %p ctx %p  ctx->space_used=%d  , 
push_seq=%lld, ctx->sequence=%lld\n",
+   cil, cil->xc_ctx,
+   cil->xc_ctx->space_used,
+   cil->xc_push_seq,
+   cil->xc_ctx->sequence);
queue_work(log->l_mp->m_cil_workqueue, &cil->xc_push_work);
}
 
@@ -936,6 +960,12 @@ xlog_cil_push_background(

if (cil->xc_ctx->space_used >= XLOG_CIL_BLOCKING_SPACE_LIMIT(log)) {
trace_xfs_log_cil_wait(log, cil->xc_ctx->ticket);
ASSERT(cil->xc_ctx->space_used < log->l_logsize);
+   pr_warn("XXX pushw   cil %p ctx %p  ctx->space_used=%d >= %d, 
push_seq=%lld, ctx->sequence=%lld\n",
+   cil, cil->xc_ctx,
+   cil->xc_ctx->space_used,
+   XLOG_CIL_BLOCKING_SPACE_LIMIT(log),
+   cil->xc_push_seq,
+   cil->xc_ctx->sequence);
xlog_wait(&cil->xc_push_wait, &cil->xc_push_lock);
return;
}

=

14606 "XXX" lines logged before deadlo

Re: [PATCH RFC] KVM: arm64: vgic: Decouple the check of the EnableLPIs bit from the ITS LPI translation

[Shenming Lu]

On 2020/12/31 16:57, Marc Zyngier wrote:
> Hi Shemming,
> 
> On 2020-12-31 06:28, Shenming Lu wrote:
>> When the EnableLPIs bit is set to 0, any ITS LPI requests in the
>> Redistributor would be ignored. And this check is independent from
>> the ITS LPI translation. So it might be better to move the check
>> of the EnableLPIs bit out of the LPI resolving, and also add it
>> to the path that uses the translation cache.
> 
> But by doing that, you are moving the overhead of checking for
> EnableLPIs from the slow path (translation walk) to the fast
> path (cache hit), which seems counter-productive.

Oh, I didn't notice the overhead of the checking, I thought it would
be negligible...

> 
>> Besides it seems that
>> by this the invalidating of the translation cache caused by the LPI
>> disabling is unnecessary.
>>
>> Not sure if I have missed something... Thanks.
> 
> I am certainly missing the purpose of this patch.
> 
> The effect of EnableLPIs being zero is to drop the result of any
> translation (a new pending bit) on the floor. Given that, it is
> immaterial whether this causes a new translation or hits in the
> cache, as the result is still to not pend a new interrupt.
> 
> I get the feeling that you are trying to optimise for the unusual
> case where EnableLPIs is 0 *and* you have a screaming device
> injecting tons of interrupt. If that is the case, I don't think
> this is worth it.

In fact, I just found (imagining) that if the EnableLPIs bit is 0,
the kvm_vgic_v4_set_forwarding() would fail when performing the LPI
translation, but indeed we don't try to pend any interrupts there...

By the way, it seems that the LPI disabling would not affect the
injection of VLPIs...

Thanks,
Shenming

> 
> Thanks,
> 
>     M.
> 
>>
>> Signed-off-by: Shenming Lu 
>> ---
>>  arch/arm64/kvm/vgic/vgic-its.c | 9 +
>>  arch/arm64/kvm/vgic/vgic-mmio-v3.c | 4 +---
>>  2 files changed, 6 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c
>> index 40cbaca81333..f53446bc154e 100644
>> --- a/arch/arm64/kvm/vgic/vgic-its.c
>> +++ b/arch/arm64/kvm/vgic/vgic-its.c
>> @@ -683,9 +683,6 @@ int vgic_its_resolve_lpi(struct kvm *kvm, struct
>> vgic_its *its,
>>  if (!vcpu)
>>  return E_ITS_INT_UNMAPPED_INTERRUPT;
>>
>> -    if (!vcpu->arch.vgic_cpu.lpis_enabled)
>> -    return -EBUSY;
>> -
>>  vgic_its_cache_translation(kvm, its, devid, eventid, ite->irq);
>>
>>  *irq = ite->irq;
>> @@ -738,6 +735,9 @@ static int vgic_its_trigger_msi(struct kvm *kvm,
>> struct vgic_its *its,
>>  if (err)
>>  return err;
>>
>> +    if (!irq->target_vcpu->arch.vgic_cpu.lpis_enabled)
>> +    return -EBUSY;
>> +
>>  if (irq->hw)
>>  return irq_set_irqchip_state(irq->host_irq,
>>   IRQCHIP_STATE_PENDING, true);
>> @@ -757,7 +757,8 @@ int vgic_its_inject_cached_translation(struct kvm
>> *kvm, struct kvm_msi *msi)
>>
>>  db = (u64)msi->address_hi << 32 | msi->address_lo;
>>  irq = vgic_its_check_cache(kvm, db, msi->devid, msi->data);
>> -    if (!irq)
>> +
>> +    if (!irq || !irq->target_vcpu->arch.vgic_cpu.lpis_enabled)
>>  return -EWOULDBLOCK;
>>
>>  raw_spin_lock_irqsave(&irq->irq_lock, flags);
>> diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
>> b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
>> index 15a6c98ee92f..7b0749f7660d 100644
>> --- a/arch/arm64/kvm/vgic/vgic-mmio-v3.c
>> +++ b/arch/arm64/kvm/vgic/vgic-mmio-v3.c
>> @@ -242,10 +242,8 @@ static void vgic_mmio_write_v3r_ctlr(struct kvm_vcpu 
>> *vcpu,
>>
>>  vgic_cpu->lpis_enabled = val & GICR_CTLR_ENABLE_LPIS;
>>
>> -    if (was_enabled && !vgic_cpu->lpis_enabled) {
>> +    if (was_enabled && !vgic_cpu->lpis_enabled)
>>  vgic_flush_pending_lpis(vcpu);
>> -    vgic_its_invalidate_cache(vcpu->kvm);
>> -    }
>>
>>  if (!was_enabled && vgic_cpu->lpis_enabled)
>>  vgic_enable_lpis(vcpu);
> 

[PATCH] vt: use flexible-array member instead of zero-length array

[Tian Tao]

Use flexible-array member introduced in C99 instead of zero-length
array. Most of zero-length array was already taken care in previous
patch [1]. Now modified few more cases which were not handled earlier.

[1]. https://patchwork.kernel.org/patch/11394197/

Signed-off-by: Tian Tao 
---
 drivers/tty/vt/vt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index d04a162..86b4c5f 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -332,7 +332,7 @@ typedef uint32_t char32_t;
  * scrolling only implies some pointer shuffling.
  */
 struct uni_screen {
-   char32_t *lines[0];
+   char32_t *lines[];
 };
 
 static struct uni_screen *vc_uniscr_alloc(unsigned int cols, unsigned int rows)
-- 
2.7.4

Re: [PATCH 1/4] net: sfp: add workaround for Realtek RTL8672 and RTL9601C chips

[Pali Rohár]

On Wednesday 30 December 2020 19:09:58 Russell King - ARM Linux admin wrote:
> On Wed, Dec 30, 2020 at 06:43:07PM +0100, Pali Rohár wrote:
> > On Wednesday 30 December 2020 18:13:15 Andrew Lunn wrote:
> > > Hi Pali
> > > 
> > > I have to agree with Russell here. I would rather have no diagnostics
> > > than untrustable diagnostics.
> > 
> > Ok!
> > 
> > So should we completely skip hwmon_device_register_with_info() call
> > if (i2c_block_size < 2) ?
> 
> I don't think that alone is sufficient - there's also the matter of
> ethtool -m which will dump that information as well, and we don't want
> to offer it to userspace in an unreliable form.

Any idea/preference how to disable access to these registers?

> For reference, here is what SFF-8472 which defines the diagnostics, says
> about this:
> 
>   To guarantee coherency of the diagnostic monitoring data, the host is
>   required to retrieve any multi-byte fields from the diagnostic
>   monitoring data structure (IE: Rx Power MSB - byte 104 in A2h, Rx Power
>   LSB - byte 105 in A2h) by the use of a single two-byte read sequence
>   across the two-wire interface interface.
> 
>   The transceiver is required to ensure that any multi-byte fields which
>   are updated with diagnostic monitoring data (e.g. Rx Power MSB - byte
>   104 in A2h, Rx Power LSB - byte 105 in A2h) must have this update done
>   in a fashion which guarantees coherency and consistency of the data. In
>   other words, the update of a multi-byte field by the transceiver must
>   not occur such that a partially updated multi-byte field can be
>   transferred to the host. Also, the transceiver shall not update a
>   multi-byte field within the structure during the transfer of that
>   multi-byte field to the host, such that partially updated data would be
>   transferred to the host.
> 
> The first paragraph is extremely definitive in how these fields shall
> be read atomically - by a _single_ two-byte read sequence. From what
> you are telling us, these modules do not support that. Therefore, by
> definition, they do *not* support proper and reliable reporting of
> diagnostic data, and are non-conformant with the SFP MSAs.
> 
> So, they are basically broken, and the diagnostics can't be used to
> retrieve data that can be said to be useful.

I agree they are broken. We really should disable access to those 16bit
registers.

Anyway here is "datasheet" to some CarlitoxxPro SFP:
https://www.docdroid.net/hRsJ560/cpgos03-0490v2-datasheet-10-pdf

And on page 10 is written:

The I2C system can support the mode of random address / single
byteread which conform to SFF-8431.

Which seems to be wrong.

> > I do not think that manufacture says something. I think that they even
> > do not know that their Realtek chips are completely broken.
> 
> Oh, they do know. I had a response from CarlitoxxPro passed to me, which
> was:

Could you give me contact address?

Anyway, we would rather should contact Realtek chip division, real
manufacture. Not CarlitoxxPro rebrander which can just "buy product"
from Realtek reseller and put its logo on stick (and maybe configuration
like sn, mac address, password and enable/disable bit for web/telnet).

>   That is a behavior related on how your router/switch try to read the
>   EEPROM, as described in the datasheet of the GPON ONU SFP, the EEPROM
>   can be read in Sequential Single-Byte mode, not in Multi-byte mode as
>   you router do, basically, your router is trying to read the full a0h
>   table in a single call, and retrieve a null response. that is normal
>   and not affect the operations of the GPON ONU SFP, because these
>   values are informational only. so the Software for your router should
>   be able to read in Single-Byte mode to read the content of the EEPROM
>   in concordance to SFF-8431
> 
> which totally misses the point that it is /not/ up to the module to
> choose whether multi-byte reads are supported or not. If they bothered
> to gain a proper understanding of the MSAs, they would have noticed that
> the device on 0xA0 is required to behave as an Atmel AT24Cxx EEPROM.
> The following from INF-8074i, which is the very first definition of the
> SFP form factor modules:
> 
>   The SFP serial ID provides access to sophisticated identification
>   information that describes the transceiver's capabilities, standard
>   interfaces, manufacturer, and other information. The serial interface
>   uses the 2-wire serial CMOS E2PROM protocol defined for the ATMEL
>   AT24C01A/02/04 family of components.
> 
> As they took less than one working day to provide the above response, I
> suspect they know full well that there's a problem - and it likely
> affects other "routers" as well.

As this issue is with all those Realtek chips I really think this issue
is in underlying Realtek chip and not in CarlitoxxPro rebranding. Seems
that they know about this issue and because it affects all GPON Realtek
SFPs with that chip that cannot do anything with it, so j

Re: [PATCH v9 1/4] dt-bindings: mfd: Fix schema warnings for pwm-leds

[Lee Jones]

On Thu, 31 Dec 2020, Pavel Machek wrote:

> Hi!
> 
> > > > The node names for devices using the pwm-leds driver follow a certain
> > > > naming scheme (now).  Parent node name is not enforced, but recommended
> > > > by DT project.
> > > > 
> > > >   DTC Documentation/devicetree/bindings/mfd/iqs62x.example.dt.yaml
> > > >   CHECK   Documentation/devicetree/bindings/mfd/iqs62x.example.dt.yaml
> > > > /home/alex/build/linux/Documentation/devicetree/bindings/mfd/iqs62x.example.dt.yaml:
> > > >  pwmleds: 'panel' does not match any of the regexes: 
> > > > '^led(-[0-9a-f]+)?$', 'pinctrl-[0-9]+'
> > > > From schema: 
> > > > /home/alex/src/linux/leds/Documentation/devicetree/bindings/leds/leds-pwm.yaml
> > > > 
> > > > Signed-off-by: Alexander Dahl 
> > > > Acked-by: Jeff LaBundy 
> > > > Acked-by: Rob Herring 
> > > 
> > > Thanks, applied.
> > 
> > Sorry, what?
> > 
> > Applied to what tree?
> 
> I took it to (local copy) of leds-next tree on. But now I realised it
> is mfd, not a LED patch, so I undone that. Sorry for the confusion.
> 
> Anyway, patch still looks good to me:
> 
> Acked-by: Pavel Machek 

Thanks Pavel.

I plan on taking this next week.

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog

Re: [PATCH RFC] KVM: arm64: vgic: Decouple the check of the EnableLPIs bit from the ITS LPI translation

[Marc Zyngier]

On 2020-12-31 11:58, Shenming Lu wrote:

On 2020/12/31 16:57, Marc Zyngier wrote:

Hi Shemming,

On 2020-12-31 06:28, Shenming Lu wrote:

When the EnableLPIs bit is set to 0, any ITS LPI requests in the
Redistributor would be ignored. And this check is independent from
the ITS LPI translation. So it might be better to move the check
of the EnableLPIs bit out of the LPI resolving, and also add it
to the path that uses the translation cache.


But by doing that, you are moving the overhead of checking for
EnableLPIs from the slow path (translation walk) to the fast
path (cache hit), which seems counter-productive.


Oh, I didn't notice the overhead of the checking, I thought it would
be negligible...


It probably doesn't show on a modern box, but some of the slower
systems might see it. Overall, this is a design decision to keep
the translation cache as simple and straightforward as possible:
if anything affects the output of the cache, we invalidate it,
and that's it.






Besides it seems that
by this the invalidating of the translation cache caused by the LPI
disabling is unnecessary.

Not sure if I have missed something... Thanks.


I am certainly missing the purpose of this patch.

The effect of EnableLPIs being zero is to drop the result of any
translation (a new pending bit) on the floor. Given that, it is
immaterial whether this causes a new translation or hits in the
cache, as the result is still to not pend a new interrupt.

I get the feeling that you are trying to optimise for the unusual
case where EnableLPIs is 0 *and* you have a screaming device
injecting tons of interrupt. If that is the case, I don't think
this is worth it.


In fact, I just found (imagining) that if the EnableLPIs bit is 0,
the kvm_vgic_v4_set_forwarding() would fail when performing the LPI
translation, but indeed we don't try to pend any interrupts there...

By the way, it seems that the LPI disabling would not affect the
injection of VLPIs...


Yes, good point. We could unmap the VPE from all ITS, which would result
in all translations to be discarded, but this has the really bad side
effect of *also* preventing the delivery of vSGIs, which isn't what
you'd expect.

Overall, I don't think there is a good way to support this, and maybe
we should just prevent EnableLPIs to be turned off when using direct
injection. After all, the architecture does allow that for GICv3
implementations, which is what we emulate.

Thanks,

M.
--
Jazz is not dead. It just smells funny...

[PATCH 2/4] regulator: qcom-rpmh-regulator: correct hfsmps515 definition

[Dmitry Baryshkov]

According to the datasheet pm8009's HFS515 regulators have 16mV
resolution rather than declared 1.6 mV. Correct the resolution.

Signed-off-by: Dmitry Baryshkov 
Fixes: 06369bcc15a1 ("regulator: qcom-rpmh: Add support for SM8150")
---
 drivers/regulator/qcom-rpmh-regulator.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/regulator/qcom-rpmh-regulator.c 
b/drivers/regulator/qcom-rpmh-regulator.c
index fe030ec4b7db..c395a8dda6f7 100644
--- a/drivers/regulator/qcom-rpmh-regulator.c
+++ b/drivers/regulator/qcom-rpmh-regulator.c
@@ -726,7 +726,7 @@ static const struct rpmh_vreg_hw_data pmic5_ftsmps510 = {
 static const struct rpmh_vreg_hw_data pmic5_hfsmps515 = {
.regulator_type = VRM,
.ops = &rpmh_regulator_vrm_ops,
-   .voltage_range = REGULATOR_LINEAR_RANGE(280, 0, 4, 1600),
+   .voltage_range = REGULATOR_LINEAR_RANGE(280, 0, 4, 16000),
.n_voltages = 5,
.pmic_mode_map = pmic_mode_map_pmic5_smps,
.of_map_mode = rpmh_regulator_pmic4_smps_of_map_mode,
-- 
2.29.2

[PATCH 0/4] regulator: fix pm8009 bindings on sm8250

[Dmitry Baryshkov]

PM8009 has special revision (P=1), which is to be used for sm8250
platform. The major difference is the S2 regulator which supplies 0.95 V
instead of 2.848V. Declare regulators data to be used for this chip
revision. The datasheet calls the chip just pm8009-1, so use the same
name.

[PATCH 4/4] arm64: dts: qcom: qrb5165-rb5: fix pm8009 regulators

[Dmitry Baryshkov]

Fix pm8009 compatibility string to reference pm8009 revision specific to
sm8250 platform. Also add S2 regulator to be used for qca639x.

Signed-off-by: Dmitry Baryshkov 
Fixes: b1d2674e6121 ("arm64: dts: qcom: Add basic devicetree support for 
QRB5165 RB5")
---
 arch/arm64/boot/dts/qcom/qrb5165-rb5.dts | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts 
b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
index cbced45d7f51..5c1cc836920f 100644
--- a/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
+++ b/arch/arm64/boot/dts/qcom/qrb5165-rb5.dts
@@ -140,7 +140,7 @@ qca639x: qca639x {
 
 &apps_rsc {
pm8009-rpmh-regulators {
-   compatible = "qcom,pm8009-rpmh-regulators";
+   compatible = "qcom,pm8009-1-rpmh-regulators";
qcom,pmic-id = "f";
 
vdd-s1-supply = <&vph_pwr>;
@@ -149,6 +149,13 @@ pm8009-rpmh-regulators {
vdd-l5-l6-supply = <&vreg_bob>;
vdd-l7-supply = <&vreg_s4a_1p8>;
 
+   vreg_s2f_0p95: smps2 {
+   regulator-name = "vreg_s2f_0p95";
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <952000>;
+   regulator-initial-mode = ;
+   };
+
vreg_l1f_1p1: ldo1 {
regulator-name = "vreg_l1f_1p1";
regulator-min-microvolt = <1104000>;
-- 
2.29.2

[PATCH 3/4] regulator: qcom-rpmh-regulator: add pm8009-1 chip revision

[Dmitry Baryshkov]

PM8009 has special revision (P=1), which is to be used for sm8250
platform. The major difference is the S2 regulator which supplies 0.95 V
instead of 2.848V. Declare regulators data to be used for this chip
revision. The datasheet calls the chip just pm8009-1, so use the same
name.

Signed-off-by: Dmitry Baryshkov 
Fixes: 06369bcc15a1 ("regulator: qcom-rpmh: Add support for SM8150")
---
 drivers/regulator/qcom-rpmh-regulator.c | 26 +
 1 file changed, 26 insertions(+)

diff --git a/drivers/regulator/qcom-rpmh-regulator.c 
b/drivers/regulator/qcom-rpmh-regulator.c
index c395a8dda6f7..98320e1d8bf6 100644
--- a/drivers/regulator/qcom-rpmh-regulator.c
+++ b/drivers/regulator/qcom-rpmh-regulator.c
@@ -732,6 +732,15 @@ static const struct rpmh_vreg_hw_data pmic5_hfsmps515 = {
.of_map_mode = rpmh_regulator_pmic4_smps_of_map_mode,
 };
 
+static const struct rpmh_vreg_hw_data pmic5_hfsmps515_1 = {
+   .regulator_type = VRM,
+   .ops = &rpmh_regulator_vrm_ops,
+   .voltage_range = REGULATOR_LINEAR_RANGE(90, 0, 4, 16000),
+   .n_voltages = 5,
+   .pmic_mode_map = pmic_mode_map_pmic5_smps,
+   .of_map_mode = rpmh_regulator_pmic4_smps_of_map_mode,
+};
+
 static const struct rpmh_vreg_hw_data pmic5_bob = {
.regulator_type = VRM,
.ops = &rpmh_regulator_vrm_bypass_ops,
@@ -932,6 +941,19 @@ static const struct rpmh_vreg_init_data pm8009_vreg_data[] 
= {
{},
 };
 
+static const struct rpmh_vreg_init_data pm8009_1_vreg_data[] = {
+   RPMH_VREG("smps1",  "smp%s1",  &pmic5_hfsmps510, "vdd-s1"),
+   RPMH_VREG("smps2",  "smp%s2",  &pmic5_hfsmps515_1, "vdd-s2"),
+   RPMH_VREG("ldo1",   "ldo%s1",  &pmic5_nldo,  "vdd-l1"),
+   RPMH_VREG("ldo2",   "ldo%s2",  &pmic5_nldo,  "vdd-l2"),
+   RPMH_VREG("ldo3",   "ldo%s3",  &pmic5_nldo,  "vdd-l3"),
+   RPMH_VREG("ldo4",   "ldo%s4",  &pmic5_nldo,  "vdd-l4"),
+   RPMH_VREG("ldo5",   "ldo%s5",  &pmic5_pldo,  "vdd-l5-l6"),
+   RPMH_VREG("ldo6",   "ldo%s6",  &pmic5_pldo,  "vdd-l5-l6"),
+   RPMH_VREG("ldo7",   "ldo%s6",  &pmic5_pldo_lv,   "vdd-l7"),
+   {},
+};
+
 static const struct rpmh_vreg_init_data pm6150_vreg_data[] = {
RPMH_VREG("smps1",  "smp%s1",  &pmic5_ftsmps510, "vdd-s1"),
RPMH_VREG("smps2",  "smp%s2",  &pmic5_ftsmps510, "vdd-s2"),
@@ -1057,6 +1079,10 @@ static const struct of_device_id __maybe_unused 
rpmh_regulator_match_table[] = {
.compatible = "qcom,pm8009-rpmh-regulators",
.data = pm8009_vreg_data,
},
+   {
+   .compatible = "qcom,pm8009-1-rpmh-regulators",
+   .data = pm8009_1_vreg_data,
+   },
{
.compatible = "qcom,pm8150-rpmh-regulators",
.data = pm8150_vreg_data,
-- 
2.29.2

[PATCH 1/4] dt-bindings: regulator: qcom,rpmh-regulator: add pm8009 revision

[Dmitry Baryshkov]

PMIC pm8009 has special revision (P=1) made for sm8250 platform. The
major difference is the S2 regulator which supplies 0.95 V instead of
2.848V. Add special compatibility string for this chip revision.
The datasheet calls the chip just pm8009-1, so use the same name.

Signed-off-by: Dmitry Baryshkov 
---
 .../devicetree/bindings/regulator/qcom,rpmh-regulator.txt| 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt 
b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
index b8f0b7809c02..7d462b899473 100644
--- a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
@@ -44,6 +44,7 @@ First Level Nodes - PMIC
Definition: Must be one of below:
"qcom,pm8005-rpmh-regulators"
"qcom,pm8009-rpmh-regulators"
+   "qcom,pm8009-1-rpmh-regulators"
"qcom,pm8150-rpmh-regulators"
"qcom,pm8150l-rpmh-regulators"
"qcom,pm8350-rpmh-regulators"
-- 
2.29.2

[PATCH] x86/tsc: export tsc_khz to sysfs

[Redha Gouicem]

Export the frequency of the tsc clock to user space. This is particularly
useful for benchmarking purposes because it allows to convert tsc cycles
into time. The value is available at:
 /sys/devices/system/cpu/tsc_khz

Signed-off-by: Redha Gouicem 
---
 arch/x86/kernel/tsc.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 49d925043171..6ea991516d08 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -1412,6 +1413,15 @@ static int __init init_tsc_clocksource(void)
  */
 device_initcall(init_tsc_clocksource);
 
+/* sysfs file to export tsc_khz */
+static ssize_t tsc_khz_show(struct kobject *kobj,
+   struct kobj_attribute *attr, char *buf)
+{
+   return sprintf(buf, "%u\n", tsc_khz);
+}
+
+struct kobj_attribute tsc_khz_attr = __ATTR_RO(tsc_khz);
+
 static bool __init determine_cpu_tsc_frequencies(bool early)
 {
/* Make sure that cpu and tsc are not already calibrated */
@@ -1530,6 +1540,19 @@ void __init tsc_init(void)
detect_art();
 }
 
+static int __init tsc_khz_sysfs_init(void)
+{
+   int ret = sysfs_create_file(&cpu_subsys.dev_root->kobj, 
&tsc_khz_attr.attr);
+
+   if (!ret)
+   pr_info("tsc_khz exported in sysfs\n");
+   else
+   pr_warn("tsc_khz failed to be exported in sysfs\n");
+
+   return ret;
+}
+late_initcall(tsc_khz_sysfs_init);
+
 #ifdef CONFIG_SMP
 /*
  * If we have a constant TSC and are using the TSC for the delay loop,
-- 
2.30.0

Re: [PATCH -next] media: platform: davinci: Use DEFINE_SPINLOCK() for spinlock

[Lad, Prabhakar]

Hi Zheng,

Thank you for the patch.

On Mon, Dec 28, 2020 at 1:50 PM Zheng Yongjun  wrote:
>
> spinlock can be initialized automatically with DEFINE_SPINLOCK()
> rather than explicitly calling spin_lock_init().
>
> Signed-off-by: Zheng Yongjun 
> ---
>  drivers/media/platform/davinci/vpif.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
Reviewed-by: Lad Prabhakar 

Cheers,
Prabhakar

> diff --git a/drivers/media/platform/davinci/vpif.c 
> b/drivers/media/platform/davinci/vpif.c
> index 5e67994e62cc..f1ce10828b8e 100644
> --- a/drivers/media/platform/davinci/vpif.c
> +++ b/drivers/media/platform/davinci/vpif.c
> @@ -41,7 +41,7 @@ MODULE_ALIAS("platform:" VPIF_DRIVER_NAME);
>  #define VPIF_CH2_MAX_MODES 15
>  #define VPIF_CH3_MAX_MODES 2
>
> -spinlock_t vpif_lock;
> +DEFINE_SPINLOCK(vpif_lock);
>  EXPORT_SYMBOL_GPL(vpif_lock);
>
>  void __iomem *vpif_base;
> @@ -437,7 +437,6 @@ static int vpif_probe(struct platform_device *pdev)
> pm_runtime_enable(&pdev->dev);
> pm_runtime_get(&pdev->dev);
>
> -   spin_lock_init(&vpif_lock);
> dev_info(&pdev->dev, "vpif probe success\n");
>
> /*
> --
> 2.22.0
>

Re: [PATCH v8 13/16] dmaengine: dw-axi-dmac: Add Intel KeemBay AxiDMA handshake

[Eugeniy Paltsev]

Hi Sia Jee Heng,

see my comments inlined:

> From: Sia Jee Heng 
> Sent: Tuesday, December 29, 2020 07:47
> To: vk...@kernel.org; Eugeniy Paltsev; robh...@kernel.org
> Cc: andriy.shevche...@linux.intel.com; dmaeng...@vger.kernel.org; 
> linux-kernel@vger.kernel.org; devicet...@vger.kernel.org
> Subject: [PATCH v8 13/16] dmaengine: dw-axi-dmac: Add Intel KeemBay AxiDMA 
> handshake
> 
> Add support for Intel KeemBay AxiDMA device handshake programming.
> Device handshake number passed in to the AxiDMA shall be written to
> the Intel KeemBay AxiDMA hardware handshake registers before DMA
> operations are started.
> 
> Reviewed-by: Andy Shevchenko 
> Signed-off-by: Sia Jee Heng 
> ---
>  .../dma/dw-axi-dmac/dw-axi-dmac-platform.c| 52 +++
>  1 file changed, 52 insertions(+)
> 
> diff --git a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c 
> b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
> index 062d27c61983..5e77eb3d040f 100644
> --- a/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
> +++ b/drivers/dma/dw-axi-dmac/dw-axi-dmac-platform.c
 [snip]
> +
> +   return 0;
> +}
> +
>  /*
>   * If DW_axi_dmac sees CHx_CTL.ShadowReg_Or_LLI_Last bit of the fetched LLI
>   * as 1, it understands that the current block is the final block in the
> @@ -626,6 +668,9 @@ dw_axi_dma_chan_prep_cyclic(struct dma_chan *dchan, 
> dma_addr_t dma_addr,
> llp = hw_desc->llp;
> } while (num_periods);
> 
> +   if (dw_axi_dma_set_hw_channel(chan->chip, chan->hw_handshake_num, 
> true))
> +   goto err_desc_get;
> +

In this implementation 'dw_axi_dma_chan_prep_cyclic' callback will fail if
we don't have APB registers which are only specific for KeemBay.
Looking for the code of 'dw_axi_dma_chan_prep_cyclic' I don't see the reason
why it shouldn't work for vanila DW AXI DMAC without this extension. So, could
you please change this so we wouldn't reject dw_axi_dma_chan_prep_cyclic in case
of APB registers are missed.

> return vchan_tx_prep(&chan->vc, &desc->vd, flags);
> 
>  err_desc_get:
> @@ -684,6 +729,9 @@ dw_axi_dma_chan_prep_slave_sg(struct dma_chan *dchan, 
> struct scatterlist *sgl,
> llp = hw_desc->llp;
> } while (sg_len);
> 
> +   if (dw_axi_dma_set_hw_channel(chan->chip, chan->hw_handshake_num, 
> true))
> +   goto err_desc_get;
> +

Same here.


> return vchan_tx_prep(&chan->vc, &desc->vd, flags);
> 
>  err_desc_get:
> @@ -959,6 +1007,10 @@ static int dma_chan_terminate_all(struct dma_chan 
> *dchan)
> dev_warn(dchan2dev(dchan),
>  "%s failed to stop\n", axi_chan_name(chan));
> 
> +   if (chan->direction != DMA_MEM_TO_MEM)
> +   dw_axi_dma_set_hw_channel(chan->chip,
> + chan->hw_handshake_num, false);
> +
> spin_lock_irqsave(&chan->vc.lock, flags);
> 
> vchan_get_all_descriptors(&chan->vc, &head);
> --
> 2.18.0
> 

sound/hda/intel-dsp-config.c:360: undefined reference to `sdw_intel_acpi_scan'

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   f6e1ea19649216156576aeafa784e3b4cee45549
commit: a115ab9b8b93e7f0ff28a4fc869a3222ae921edd ASoC: SOF: Intel: add build 
support for SoundWire
date:   4 months ago
config: i386-randconfig-s031-20201231 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.3-184-g1b896707-dirty
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a115ab9b8b93e7f0ff28a4fc869a3222ae921edd
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout a115ab9b8b93e7f0ff28a4fc869a3222ae921edd
# save the attached .config to linux build tree
make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   ld: sound/hda/intel-dsp-config.o: in function 
`snd_intel_dsp_check_soundwire':
>> sound/hda/intel-dsp-config.c:360: undefined reference to 
>> `sdw_intel_acpi_scan'


vim +360 sound/hda/intel-dsp-config.c

82d9d54a6c0ee8b Jaroslav Kysela  2019-10-22  350  
0650857570d1614 Pierre-Louis Bossart 2020-04-09  351  #if 
IS_ENABLED(CONFIG_SND_SOC_SOF_INTEL_SOUNDWIRE)
0650857570d1614 Pierre-Louis Bossart 2020-04-09  352  static int 
snd_intel_dsp_check_soundwire(struct pci_dev *pci)
0650857570d1614 Pierre-Louis Bossart 2020-04-09  353  {
0650857570d1614 Pierre-Louis Bossart 2020-04-09  354struct 
sdw_intel_acpi_info info;
0650857570d1614 Pierre-Louis Bossart 2020-04-09  355acpi_handle handle;
0650857570d1614 Pierre-Louis Bossart 2020-04-09  356int ret;
0650857570d1614 Pierre-Louis Bossart 2020-04-09  357  
0650857570d1614 Pierre-Louis Bossart 2020-04-09  358handle = 
ACPI_HANDLE(&pci->dev);
0650857570d1614 Pierre-Louis Bossart 2020-04-09  359  
0650857570d1614 Pierre-Louis Bossart 2020-04-09 @360ret = 
sdw_intel_acpi_scan(handle, &info);
0650857570d1614 Pierre-Louis Bossart 2020-04-09  361if (ret < 0)
0650857570d1614 Pierre-Louis Bossart 2020-04-09  362return ret;
0650857570d1614 Pierre-Louis Bossart 2020-04-09  363  
0650857570d1614 Pierre-Louis Bossart 2020-04-09  364return info.link_mask;
0650857570d1614 Pierre-Louis Bossart 2020-04-09  365  }
0650857570d1614 Pierre-Louis Bossart 2020-04-09  366  #else
0650857570d1614 Pierre-Louis Bossart 2020-04-09  367  static int 
snd_intel_dsp_check_soundwire(struct pci_dev *pci)
0650857570d1614 Pierre-Louis Bossart 2020-04-09  368  {
0650857570d1614 Pierre-Louis Bossart 2020-04-09  369return 0;
0650857570d1614 Pierre-Louis Bossart 2020-04-09  370  }
0650857570d1614 Pierre-Louis Bossart 2020-04-09  371  #endif
0650857570d1614 Pierre-Louis Bossart 2020-04-09  372  

:: The code at line 360 was first introduced by commit
:: 0650857570d161486a95d37bc8682628881ae2da ALSA: hda: add autodetection 
for SoundWire

:: TO: Pierre-Louis Bossart 
:: CC: Takashi Iwai 

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

Re: [PATCH] ARM: picoxcell: fix missing interrupt-parent properties

[Jamie Iles]

Hi Arnd,

On Wed, Dec 30, 2020 at 04:20:05PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> dtc points out that the interrupts for some devices are not parsable:
> 
> picoxcell-pc3x2.dtsi:45.19-49.5: Warning (interrupts_property): 
> /paxi/gem@3: Missing interrupt-parent
> picoxcell-pc3x2.dtsi:51.21-55.5: Warning (interrupts_property): 
> /paxi/dmac@4: Missing interrupt-parent
> picoxcell-pc3x2.dtsi:57.21-61.5: Warning (interrupts_property): 
> /paxi/dmac@5: Missing interrupt-parent
> picoxcell-pc3x2.dtsi:233.21-237.5: Warning (interrupts_property): 
> /rwid-axi/axi2pico@c000: Missing interrupt-parent
> 
> There are two VIC instances, so it's not clear which one needs to be
> used. I found the BSP sources that reference VIC0, so use that:
> 
> https://github.com/r1mikey/meta-picoxcell/blob/master/recipes-kernel/linux/linux-picochip-3.0/0001-picoxcell-support-for-Picochip-picoXcell-SoC.patch
> 
> Signed-off-by: Arnd Bergmann 

Rob has a series to remove Picoxcell as there's no active development on 
this anymore and Intel have stopped producing the chips.

Thanks,

Jamie

[PATCH v5 2/6] mfd: ahc1ec0: Add Advantech EC include file used by dt-bindings

[Campion Kang]

This files defines the sud-device types and hwmon profiles support by
Advantech embedded controller.

Signed-off-by: Campion Kang 
---
 include/dt-bindings/mfd/ahc1ec0-dt.h | 25 +
 1 file changed, 25 insertions(+)
 create mode 100644 include/dt-bindings/mfd/ahc1ec0-dt.h

diff --git a/include/dt-bindings/mfd/ahc1ec0-dt.h 
b/include/dt-bindings/mfd/ahc1ec0-dt.h
new file mode 100644
index ..389a7a7f8f02
--- /dev/null
+++ b/include/dt-bindings/mfd/ahc1ec0-dt.h
@@ -0,0 +1,25 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Device Tree defines for Advantech Embedded Controller (AHC1EC0)
+ */
+
+#ifndef _DT_BINDINGS_MFD_AHC1EC0_H
+#define _DT_BINDINGS_MFD_AHC1EC0_H
+
+/* Sub-device Definitions */
+#define AHC1EC0_SUBDEV_BRIGHTNESS 0x0
+#define AHC1EC0_SUBDEV_EEPROM 0x1
+#define AHC1EC0_SUBDEV_GPIO   0x2
+#define AHC1EC0_SUBDEV_HWMON  0x3
+#define AHC1EC0_SUBDEV_LED0x4
+#define AHC1EC0_SUBDEV_WDT0x5
+
+/* HWMON Profile Definitions */
+#define AHC1EC0_HWMON_PRO_TEMPLATE 0x0
+#define AHC1EC0_HWMON_PRO_TPC5XXX  0x1
+#define AHC1EC0_HWMON_PRO_PRVR40x2
+#define AHC1EC0_HWMON_PRO_UNO2271G 0x3
+#define AHC1EC0_HWMON_PRO_UNO1172A 0x4
+#define AHC1EC0_HWMON_PRO_UNO1372G 0x5
+
+#endif /* _DT_BINDINGS_MFD_AHC1EC0_H */
-- 
2.17.1

[PATCH v5 3/6] dt-bindings: mfd: ahc1ec0.yaml: Add Advantech embedded controller - AHC1EC0

[Campion Kang]

Add DT binding schema for Advantech embedded controller AHC1EC0.

Signed-off-by: Campion Kang 
---
 .../devicetree/bindings/mfd/ahc1ec0.yaml  | 69 +++
 1 file changed, 69 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/ahc1ec0.yaml

diff --git a/Documentation/devicetree/bindings/mfd/ahc1ec0.yaml 
b/Documentation/devicetree/bindings/mfd/ahc1ec0.yaml
new file mode 100644
index ..da57d782ea77
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ahc1ec0.yaml
@@ -0,0 +1,69 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/ahc1ec0.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Advantech Embedded Controller (AHC1EC0)
+
+maintainers:
+  - Campion Kang 
+
+description: |
+  AHC1EC0 is one of the embedded controllers used by Advantech to provide 
several
+  functions such as watchdog, hwmon, brightness, etc. Advantech related 
applications
+  can control the whole system via these functions.
+
+properties:
+  compatible:
+const: advantech,ahc1ec0
+
+  advantech,sub-dev-nb:
+description:
+  The number of sub-devices specified in the platform.
+$ref: /schemas/types.yaml#/definitions/uint32
+maxItems: 1
+
+  advantech,sub-dev:
+description:
+  A list of the sub-devices supported in the platform. Defines for the
+  appropriate values can found in dt-bindings/mfd/ahc1ec0.h.
+$ref: "/schemas/types.yaml#/definitions/uint32-array"
+minItems: 1
+maxItems: 6
+
+  advantech,hwmon-profile:
+description:
+  The number of sub-devices specified in the platform. Defines for the
+  hwmon profiles can found in dt-bindings/mfd/ahc1ec0.
+$ref: /schemas/types.yaml#/definitions/uint32
+maxItems: 1
+
+required:
+  - compatible
+  - advantech,sub-dev-nb
+  - advantech,sub-dev
+
+if:
+  properties:
+advantech,sub-dev:
+  contains:
+const: 0x3
+then:
+  required:
+- advantech,hwmon-profile
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+ahc1ec0 {
+compatible = "advantech,ahc1ec0";
+
+advantech,sub-dev-nb = <2>;
+advantech,sub-dev = ;
+
+advantech,hwmon-profile = ;
+};
-- 
2.17.1

[PATCH v5 4/6] mfd: ahc1ec0: Add support for Advantech embedded controller

[Campion Kang]

AHC1EC0 is the embedded controller driver for Advantech industrial
products. This provides sub-devices such as hwmon and watchdog, and also
expose functions for sub-devices to read/write the value to embedded
controller.

Signed-off-by: Campion Kang 
---
 drivers/mfd/Kconfig |  10 +
 drivers/mfd/Makefile|   2 +
 drivers/mfd/ahc1ec0.c   | 824 
 include/linux/mfd/ahc1ec0.h | 285 +
 4 files changed, 1121 insertions(+)
 create mode 100644 drivers/mfd/ahc1ec0.c
 create mode 100644 include/linux/mfd/ahc1ec0.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index bdfce7b15621..4d241c8fba0c 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -2154,5 +2154,15 @@ config MFD_INTEL_M10_BMC
  additional drivers must be enabled in order to use the functionality
  of the device.
 
+config MFD_AHC1EC0
+   tristate "Advantech Embedded Controller Module"
+   depends on X86
+   select MFD_CORE
+   help
+ This is the core function that for Advantech EC drivers. It
+ includes the sub-devices such as hwmon, watchdog, etc. And also
+ provides expose functions for sub-devices to read/write the value
+ to embedded controller.
+
 endmenu
 endif
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 14fdb188af02..a6af9d8825f4 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -268,3 +268,5 @@ obj-$(CONFIG_MFD_KHADAS_MCU)+= khadas-mcu.o
 obj-$(CONFIG_SGI_MFD_IOC3) += ioc3.o
 obj-$(CONFIG_MFD_SIMPLE_MFD_I2C)   += simple-mfd-i2c.o
 obj-$(CONFIG_MFD_INTEL_M10_BMC)   += intel-m10-bmc.o
+
+obj-$(CONFIG_MFD_AHC1EC0)  += ahc1ec0.o
diff --git a/drivers/mfd/ahc1ec0.c b/drivers/mfd/ahc1ec0.c
new file mode 100644
index ..12d5743e8c69
--- /dev/null
+++ b/drivers/mfd/ahc1ec0.c
@@ -0,0 +1,824 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Advantech embedded controller core driver AHC1EC0
+ *
+ * Copyright 2020 Advantech IIoT Group
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRV_NAME  "ahc1ec0"
+
+enum {
+   ADVEC_SUBDEV_BRIGHTNESS = 0,
+   ADVEC_SUBDEV_EEPROM,
+   ADVEC_SUBDEV_GPIO,
+   ADVEC_SUBDEV_HWMON,
+   ADVEC_SUBDEV_LED,
+   ADVEC_SUBDEV_WDT,
+   ADVEC_SUBDEV_MAX,
+};
+
+/* Wait IBF (Input Buffer Full) clear */
+static int ec_wait_write(void)
+{
+   int i;
+
+   for (i = 0; i < EC_MAX_TIMEOUT_COUNT; i++) {
+   if ((inb(EC_COMMAND_PORT) & EC_COMMAND_BIT_IBF) == 0)
+   return 0;
+
+   udelay(EC_RETRY_UDELAY);
+   }
+
+   return -ETIMEDOUT;
+}
+
+/* Wait OBF (Output Buffer Full) data ready */
+static int ec_wait_read(void)
+{
+   int i;
+
+   for (i = 0; i < EC_MAX_TIMEOUT_COUNT; i++) {
+   if ((inb(EC_COMMAND_PORT) & EC_COMMAND_BIT_OBF) != 0)
+   return 0;
+
+   udelay(EC_RETRY_UDELAY);
+   }
+
+   return -ETIMEDOUT;
+}
+
+/* Read data from EC HW RAM, the process is the following:
+ * Step 0. Wait IBF clear to send command
+ * Step 1. Send read command to EC command port
+ * Step 2. Wait IBF clear that means command is got by EC
+ * Step 3. Send read address to EC data port
+ * Step 4. Wait OBF data ready
+ * Step 5. Get data from EC data port
+ */
+int read_hw_ram(struct adv_ec_platform_data *adv_ec_data, unsigned char addr, 
unsigned char *data)
+{
+   int ret;
+
+   mutex_lock(&adv_ec_data->lock);
+
+   ret = ec_wait_write();
+   if (ret)
+   goto error;
+   outb(EC_HW_RAM_READ, EC_COMMAND_PORT);
+
+   ret = ec_wait_write();
+   if (ret)
+   goto error;
+   outb(addr, EC_STATUS_PORT);
+
+   ret = ec_wait_read();
+   if (ret)
+   goto error;
+   *data = inb(EC_STATUS_PORT);
+
+   mutex_unlock(&adv_ec_data->lock);
+
+   return ret;
+
+error:
+   mutex_unlock(&adv_ec_data->lock);
+   dev_err(adv_ec_data->dev, "%s: Wait for IBF or OBF too long. line: 
%d\n", __func__,
+  __LINE__);
+
+   return ret;
+}
+
+/* Write data to EC HW RAM
+ * Step 0. Wait IBF clear to send command
+ * Step 1. Send write command to EC command port
+ * Step 2. Wait IBF clear that means command is got by EC
+ * Step 3. Send write address to EC data port
+ * Step 4. Wait IBF clear that means command is got by EC
+ * Step 5. Send data to EC data port
+ */
+int write_hw_ram(struct adv_ec_platform_data *adv_ec_data, unsigned char addr, 
unsigned char data)
+{
+   int ret;
+
+   mutex_lock(&adv_ec_data->lock);
+
+   ret = ec_wait_write();
+   if (ret)
+   goto error;
+   outb(EC_HW_RAM_WRITE, EC_COMMAND_PORT);
+
+   ret = ec_wait_write();
+   if (ret)
+   goto error;
+   outb(addr, EC_STATUS_PORT);
+
+   ret = e

[PATCH v5 5/6] hwmon: ahc1ec0-hwmon: Add sub-device hwmon for Advantech embedded controller

[Campion Kang]

This is one of sub-device driver for Advantech embedded controller
AHC1EC0. This driver provides sysfs ABI for Advantech related
applications to monitor the system status.

Signed-off-by: Campion Kang 
---
 drivers/hwmon/Kconfig |  10 +
 drivers/hwmon/Makefile|   1 +
 drivers/hwmon/ahc1ec0-hwmon.c | 398 ++
 3 files changed, 409 insertions(+)
 create mode 100644 drivers/hwmon/ahc1ec0-hwmon.c

diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 1ecf697d8d99..cf4a0eb863b0 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -2139,6 +2139,16 @@ config SENSORS_INTEL_M10_BMC_HWMON
  sensors monitor various telemetry data of different components on the
  card, e.g. board temperature, FPGA core temperature/voltage/current.
 
+config SENSORS_AHC1EC0_HWMON
+   tristate "Advantech AHC1 EC Hardware Monitor Function"
+   depends on MFD_AHC1EC0
+   help
+ This driver provide support for the hardware monitoring functionality
+ for Advantech AHC1EC0 embedded controller on the board.
+
+ This driver provides the sysfs attributes for applications to monitor
+ the system status, including system temperatures, voltages, current.
+
 if ACPI
 
 comment "ACPI drivers"
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 09a86c5e1d29..0c37747e8c4f 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_SENSORS_ADT7411) += adt7411.o
 obj-$(CONFIG_SENSORS_ADT7462)  += adt7462.o
 obj-$(CONFIG_SENSORS_ADT7470)  += adt7470.o
 obj-$(CONFIG_SENSORS_ADT7475)  += adt7475.o
+obj-$(CONFIG_SENSORS_AHC1EC0_HWMON)+= ahc1ec0-hwmon.o
 obj-$(CONFIG_SENSORS_AMD_ENERGY) += amd_energy.o
 obj-$(CONFIG_SENSORS_APPLESMC) += applesmc.o
 obj-$(CONFIG_SENSORS_ARM_SCMI) += scmi-hwmon.o
diff --git a/drivers/hwmon/ahc1ec0-hwmon.c b/drivers/hwmon/ahc1ec0-hwmon.c
new file mode 100644
index ..a05d2c0a25ad
--- /dev/null
+++ b/drivers/hwmon/ahc1ec0-hwmon.c
@@ -0,0 +1,398 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * HWMON Driver for Advantech Embedded Controller chip AHC1EC0
+ *
+ * Copyright 2020, Advantech IIoT Group
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct adv_hwmon_profile {
+   int offset;
+   unsigned long resolution, resolution_vin, resolution_sys, 
resolution_curr, resolution_power;
+   unsigned long r1, r1_vin, r1_sys, r1_curr, r1_power;
+   unsigned long r2, r2_vin, r2_sys, r2_curr, r2_power;
+   const struct attribute_group ec_hwmon_group;
+};
+
+struct EC_HWMON_DATA {
+   unsigned char temperature[3];
+   unsigned char ec_current[5];
+   unsigned char power[5];
+   char *bios_product_name;
+   int voltage[7];
+
+   struct device *dev, *hwmon_dev;
+   struct HW_PIN_TBL pin_tbl;
+   struct EC_SMBOEM0 ec_smboem0;
+   struct adv_hwmon_profile *profile;
+};
+struct EC_HWMON_DATA lmsensor_data;
+
+static ssize_t get_ec_in1_label(struct device *dev, struct device_attribute 
*attr, char *buf)
+{
+   return  sprintf(buf, "VBAT\n");
+}
+
+static ssize_t get_ec_in2_label(struct device *dev, struct device_attribute 
*attr, char *buf)
+{
+   return  sprintf(buf, "5VSB\n");
+}
+
+static ssize_t get_ec_in3_label(struct device *dev, struct device_attribute 
*attr, char *buf)
+{
+   return  sprintf(buf, "VIN\n");
+}
+
+static ssize_t get_ec_in4_label(struct device *dev, struct device_attribute 
*attr, char *buf)
+{
+   return  sprintf(buf, "VCORE\n");
+}
+
+static ssize_t get_ec_temp2_label(struct device *dev, struct device_attribute 
*attr, char *buf)
+{
+   return sprintf(buf, "Temp CPU\n");
+}
+
+static ssize_t get_ec_temp2_crit(struct device *dev, struct device_attribute 
*attr, char *buf)
+{
+   return sprintf(buf, "10\n");
+}
+
+static ssize_t get_ec_temp2_crit_alarm(struct device *dev, struct 
device_attribute *attr, char *buf)
+{
+   return sprintf(buf, "0\n");
+}
+
+static ssize_t get_ec_in1_input(struct device *dev, struct device_attribute 
*attr, char *buf)
+{
+   unsigned char temp;
+   unsigned char voltage = 0;
+   struct HW_PIN_TBL *ptbl = &lmsensor_data.pin_tbl;
+   struct adv_hwmon_profile *profile = lmsensor_data.profile;
+   struct adv_ec_platform_data *adv_ec_data = dev_get_drvdata(dev);
+
+   temp = read_ad_value(adv_ec_data, ptbl->vbat[0], ptbl->vbat[1]);
+
+   if (profile->r2 != 0)
+   voltage = temp * (profile->r1 + profile->r2) / profile->r2;
+
+   if (profile->resolution != 0)
+   voltage =  temp * profile->resolution / 1000 / 1000;
+
+   if (profile->offset != 0)
+   voltage += (int)profile->offset * 100;
+
+   lmsensor_data.voltage[0] = 10*voltage;
+
+   return 

[PATCH v5 1/6] MAINTAINERS: Add Advantech AHC1 embedded controller entry

[Campion Kang]

Add Advantech AHC1 embedded controller entry

Signed-off-by: Campion Kang 
---
 MAINTAINERS | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 546aa66428c9..20766da2e794 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -562,6 +562,16 @@ S: Maintained
 F: Documentation/scsi/advansys.rst
 F: drivers/scsi/advansys.c
 
+ADVANTECH EMBEDDED CONTROLLER DRIVER
+M: Campion Kang 
+L: linux-kernel@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/mfd/ahc1ec0.yaml
+F: drivers/hwmon/ahc1ec0-hwmon.c
+F: drivers/mfd/ahc1ec0.c
+F: drivers/watchdog/ahc1ec0-wdt.c
+F: include/dt-bindings/mfd/ahc1ec0-dt.h
+
 ADXL34X THREE-AXIS DIGITAL ACCELEROMETER DRIVER (ADXL345/ADXL346)
 M: Michael Hennerich 
 S: Supported
-- 
2.17.1

[PATCH v5 6/6] watchdog: ahc1ec0-wdt: Add sub-device watchdog for Advantech embedded controller

[Campion Kang]

This is one of sub-device driver for Advantech embedded controller
AHC1EC0. This driver provide watchdog functionality for Advantech
related applications to restart the system.

Signed-off-by: Campion Kang 
---
 drivers/watchdog/Kconfig   |  11 ++
 drivers/watchdog/Makefile  |   1 +
 drivers/watchdog/ahc1ec0-wdt.c | 285 +
 3 files changed, 297 insertions(+)
 create mode 100644 drivers/watchdog/ahc1ec0-wdt.c

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 7ff941e71b79..b8ea2743899b 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1636,6 +1636,17 @@ config NIC7018_WDT
  To compile this driver as a module, choose M here: the module will be
  called nic7018_wdt.
 
+config AHC1EC0_WDT
+   tristate "Advantech AHC1 EC Watchdog Function"
+   depends on MFD_AHC1EC0
+   help
+ This is sub-device for Advantech AHC1EC0 embedded controller.
+
+ This driver provide watchdog functionality for Advantech related
+ applications to restart the system.
+ To compile thie driver as a module, choose M here: the module will be
+ called ahc1ec0-wdt.
+
 # M68K Architecture
 
 config M54xx_WATCHDOG
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 5c74ee19d441..7190811b1e50 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -145,6 +145,7 @@ obj-$(CONFIG_INTEL_MID_WATCHDOG) += intel-mid_wdt.o
 obj-$(CONFIG_INTEL_MEI_WDT) += mei_wdt.o
 obj-$(CONFIG_NI903X_WDT) += ni903x_wdt.o
 obj-$(CONFIG_NIC7018_WDT) += nic7018_wdt.o
+obj-$(CONFIG_AHC1EC0_WDT) += ahc1ec0-wdt.o
 obj-$(CONFIG_MLX_WDT) += mlx_wdt.o
 
 # M68K Architecture
diff --git a/drivers/watchdog/ahc1ec0-wdt.c b/drivers/watchdog/ahc1ec0-wdt.c
new file mode 100644
index ..ca1f74aa90df
--- /dev/null
+++ b/drivers/watchdog/ahc1ec0-wdt.c
@@ -0,0 +1,285 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Watchdog Driver for Advantech Embedded Controller chip AHC1EC0
+ *
+ * Copyright 2020, Advantech IIoT Group
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRV_NAME  "ahc1ec0-wdt"
+
+struct ec_wdt_data {
+   struct watchdog_device wdtdev;
+   struct adv_ec_platform_data *adv_ec_data;
+   struct notifier_block reboot_nb;
+   struct mutex lock_ioctl;
+   int is_enable;
+   int current_timeout;
+};
+
+#define EC_WDT_MIN_TIMEOUT 1   /* The watchdog devices minimum timeout value 
(in seconds). */
+#define EC_WDT_MAX_TIMEOUT 600  /* The watchdog devices maximum timeout value 
(in seconds) */
+#define EC_WDT_DEFAULT_TIMEOUT 45
+
+static int set_delay(struct adv_ec_platform_data *adv_ec_data, unsigned short 
delay_timeout_in_ms)
+{
+   if (write_hw_ram(adv_ec_data, EC_RESET_DELAY_TIME_L, 
delay_timeout_in_ms & 0x00FF)) {
+   pr_err("Failed to set Watchdog Retset Time Low byte.");
+   return -EINVAL;
+   }
+
+   if (write_hw_ram(adv_ec_data, EC_RESET_DELAY_TIME_H, 
(delay_timeout_in_ms & 0xFF00) >> 8)) {
+   pr_err("Failed to set Watchdog Retset Time Hight byte.");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+static int advwdt_set_heartbeat(unsigned long t)
+{
+   if (t < 1 || t > 6553) {
+   pr_err("%s: the input timeout is out of range.",  __func__);
+   pr_err("Please choose valid data between 1 ~ 6553.");
+   return -EINVAL;
+   }
+
+   return (t * 10);
+}
+
+/* Notifier for system down */
+static int advwdt_notify_sys(struct notifier_block *nb, unsigned long code, 
void *data)
+{
+   struct watchdog_device *wdd;
+   struct ec_wdt_data *ec_wdt_data;
+
+   wdd = container_of(nb, struct watchdog_device, reboot_nb);
+   if (!wdd)
+   return NOTIFY_BAD;
+
+   ec_wdt_data = watchdog_get_drvdata(wdd);
+   if (!ec_wdt_data)
+   return NOTIFY_BAD;
+
+   if (code == SYS_DOWN || code == SYS_HALT) {
+   /* Turn the WDT off */
+   if (write_hwram_command(ec_wdt_data->adv_ec_data, EC_WDT_STOP)) 
{
+   pr_err("Failed to set Watchdog stop.");
+   return -EINVAL;
+   }
+   ec_wdt_data->is_enable = 0;
+   pr_info("%s: notify sys shutdown", __func__);
+   }
+
+   return NOTIFY_DONE;
+}
+
+static int ec_wdt_start(struct watchdog_device *wdd)
+{
+   int ret;
+   int timeout, timeout_in_ms;
+   struct ec_wdt_data *ec_wdt_data = watchdog_get_drvdata(wdd);
+   struct adv_ec_platform_data *adv_ec_data;
+
+   dev_dbg(wdd->parent, "%s\n", __func__);
+
+   adv_ec_data = ec_wdt_data->adv_ec_data;
+   timeout = wdd->timeout; /* The watchdog devices timeout value (in 
seconds). */
+
+   mutex_lock(&ec_wdt_dat

Re: [PATCH v3 09/15] media: sunxi: Add support for the A31 MIPI CSI-2 controller

[Paul Kocialkowski]

Hi,

On Mon 14 Dec 20, 12:39, Maxime Ripard wrote:
> On Fri, Dec 11, 2020 at 04:57:02PM +0100, Paul Kocialkowski wrote:
> > +#define sun6i_mipi_csi2_subdev_video(subdev) \
> > +   container_of(subdev, struct sun6i_mipi_csi2_video, subdev)
> > +
> > +#define sun6i_mipi_csi2_video_dev(video) \
> > +   container_of(video, struct sun6i_mipi_csi2_dev, video)
> 
> Isn't it a bit unsafe?
> 
> The second subdev and video here is not the variable passed in the macro
> but the field in the structure, so any attempt at using those two macros
> with anything but a variable named subdev or video will result in a
> compilation issue?

Yep you're totally right. Will fix in the next revision!

Cheers,

Paul

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: [PATCH v5 2/2] media: i2c: Add support for the OV5648 image sensor

[Paul Kocialkowski]

Hi Sakari,

On Mon 21 Dec 20, 00:39, Sakari Ailus wrote:
> Hi Paul,
> 
> Thanks for the update.
> 
> A few more small issues below that I didn't notice earlier. The comments
> apply to the other driver as well I believe.

Thanks for the review, I'll address your comments in the next version for
both drivers!

Cheers,

Paul

> On Fri, Dec 11, 2020 at 04:40:27PM +0100, Paul Kocialkowski wrote:
> > The OV5648 is a 5 Mpx CMOS image sensor, connected via MIPI CSI-2
> > in a one or two lane configuration.
> > 
> > Most of the features of the hardware are supported, including:
> > - Auto and manual exposition/gain
> > - Auto and manual white balance
> > - Horizontal and vertical flip
> > - Test patterns
> > 
> > But the following are still missing:
> > - Debanding, based on power source frequency;
> > - Exposition setting correlated to time units.
> > 
> > Signed-off-by: Paul Kocialkowski 
> > ---
> >  drivers/media/i2c/Kconfig  |   13 +
> >  drivers/media/i2c/Makefile |1 +
> >  drivers/media/i2c/ov5648.c | 2638 
> >  3 files changed, 2652 insertions(+)
> >  create mode 100644 drivers/media/i2c/ov5648.c
> > 
> > diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> > index 878f66ef2719..c0470a8b9a80 100644
> > --- a/drivers/media/i2c/Kconfig
> > +++ b/drivers/media/i2c/Kconfig
> > @@ -922,6 +922,19 @@ config VIDEO_OV5647
> >   To compile this driver as a module, choose M here: the
> >   module will be called ov5647.
> >  
> > +config VIDEO_OV5648
> > +   tristate "OmniVision OV5648 sensor support"
> > +   depends on I2C && PM && VIDEO_V4L2
> > +   select MEDIA_CONTROLLER
> > +   select VIDEO_V4L2_SUBDEV_API
> > +   select V4L2_FWNODE
> > +   help
> > + This is a Video4Linux2 sensor driver for the OmniVision
> > + OV5648 camera.
> > +
> > + To compile this driver as a module, choose M here: the
> > + module will be called ov5648.
> > +
> >  config VIDEO_OV6650
> > tristate "OmniVision OV6650 sensor support"
> > depends on I2C && VIDEO_V4L2
> > diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> > index f0a77473979d..15d4d6382582 100644
> > --- a/drivers/media/i2c/Makefile
> > +++ b/drivers/media/i2c/Makefile
> > @@ -71,6 +71,7 @@ obj-$(CONFIG_VIDEO_OV2740) += ov2740.o
> >  obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
> >  obj-$(CONFIG_VIDEO_OV5645) += ov5645.o
> >  obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
> > +obj-$(CONFIG_VIDEO_OV5648) += ov5648.o
> >  obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
> >  obj-$(CONFIG_VIDEO_OV5675) += ov5675.o
> >  obj-$(CONFIG_VIDEO_OV5695) += ov5695.o
> > diff --git a/drivers/media/i2c/ov5648.c b/drivers/media/i2c/ov5648.c
> > new file mode 100644
> > index ..4ae6b65ec258
> > --- /dev/null
> > +++ b/drivers/media/i2c/ov5648.c
> > @@ -0,0 +1,2638 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Copyright (C) 2020 Bootlin
> > + * Author: Paul Kocialkowski 
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/* Clock rate */
> > +
> > +#define OV5648_XVCLK_RATE  2400
> > +
> > +/* Register definitions */
> > +
> > +/* System */
> > +
> > +#define OV5648_SW_STANDBY_REG  0x100
> > +#define OV5648_SW_STANDBY_STREAM_ONBIT(0)
> > +
> > +#define OV5648_SW_RESET_REG0x103
> > +#define OV5648_SW_RESET_RESET  BIT(0)
> > +
> > +#define OV5648_PAD_OEN0_REG0x3000
> > +#define OV5648_PAD_OEN1_REG0x3001
> > +#define OV5648_PAD_OEN2_REG0x3002
> > +#define OV5648_PAD_OUT0_REG0x3008
> > +#define OV5648_PAD_OUT1_REG0x3009
> > +
> > +#define OV5648_CHIP_ID_H_REG   0x300a
> > +#define OV5648_CHIP_ID_H_VALUE 0x56
> > +#define OV5648_CHIP_ID_L_REG   0x300b
> > +#define OV5648_CHIP_ID_L_VALUE 0x48
> > +
> > +#define OV5648_PAD_OUT2_REG0x300d
> > +#define OV5648_PAD_SEL0_REG0x300e
> > +#define OV5648_PAD_SEL1_REG0x300f
> > +#define OV5648_PAD_SEL2_REG0x3010
> > +#define OV5648_PAD_PK_REG  0x3011
> > +#define OV5648_PAD_PK_PD_DATO_EN   BIT(7)
> > +#define OV5648_PAD_PK_DRIVE_STRENGTH_1X(0 << 5)
> > +#define OV5648_PAD_PK_DRIVE_STRENGTH_2X(2 << 5)
> > +#define OV5648_PAD_PK_FREX_N   BIT(1)
> > +
> > +#define OV5648_A_PWC_PK_O0_REG 0x3013
> > +#define OV5648_A_PWC_PK_O0_BP_REGULATOR_N  BIT(3)
> > +#define OV5648_A_PWC_PK_O1_REG 0x3014
> > +
> > +#define OV5648_MIPI_PHY0_REG   0x3016
> > +#define 

Re: [PATCH 1/3] thermal: ti-soc-thermal: Fix stuck sensor with continuous mode for 4430

[Péter Ujfalusi]

Hi Tony,

On 12/30/20 10:43 AM, Tony Lindgren wrote:
> At least for 4430, trying to use the single conversion mode eventually
> hangs the thermal sensor. This can be quite easily seen with errors:
> 
> thermal thermal_zone0: failed to read out thermal zone (-5)
> 
> Also, trying to read the temperature shows a stuck value with:
> 
> $ while true; do cat /sys/class/thermal/thermal_zone0/temp; done
> 
> Where the temperature is not rising at all with the busy loop.
> 
> Additionally, the EOCZ (end of conversion) bit is not rising on 4430 in
> single conversion mode while it works fine in continuous conversion mode.
> It is also possible that the hung temperature sensor can affect the
> thermal shutdown alert too.
> 
> Let's fix the issue by adding TI_BANDGAP_FEATURE_CONT_MODE_ONLY flag and
> use it for 4430.
> 
> Note that we also need to add udelay to for the EOCZ (end of conversion)
> bit polling as otherwise we have it time out too early on 4430. We'll be
> changing the loop to use iopoll in the following clean-up patch.

I don't yet have my setup in working condition, so I can not test these.

> Cc: Adam Ford 
> Cc: Carl Philipp Klemm 
> Cc: Eduardo Valentin 
> Cc: Merlijn Wajer 
> Cc: Pavel Machek 
> Cc: Peter Ujfalusi 
> Cc: Sebastian Reichel 
> Signed-off-by: Tony Lindgren 
> ---
>  drivers/thermal/ti-soc-thermal/omap4-thermal-data.c | 3 ++-
>  drivers/thermal/ti-soc-thermal/ti-bandgap.c | 9 +++--
>  drivers/thermal/ti-soc-thermal/ti-bandgap.h | 2 ++
>  3 files changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/thermal/ti-soc-thermal/omap4-thermal-data.c 
> b/drivers/thermal/ti-soc-thermal/omap4-thermal-data.c
> --- a/drivers/thermal/ti-soc-thermal/omap4-thermal-data.c
> +++ b/drivers/thermal/ti-soc-thermal/omap4-thermal-data.c
> @@ -58,7 +58,8 @@ omap4430_adc_to_temp[OMAP4430_ADC_END_VALUE - 
> OMAP4430_ADC_START_VALUE + 1] = {
>  const struct ti_bandgap_data omap4430_data = {
>   .features = TI_BANDGAP_FEATURE_MODE_CONFIG |
>   TI_BANDGAP_FEATURE_CLK_CTRL |
> - TI_BANDGAP_FEATURE_POWER_SWITCH,
> + TI_BANDGAP_FEATURE_POWER_SWITCH |
> + TI_BANDGAP_FEATURE_CONT_MODE_ONLY,

Can we add a comment with the observations?

>   .fclock_name = "bandgap_fclk",
>   .div_ck_name = "bandgap_fclk",
>   .conv_table = omap4430_adc_to_temp,
> diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.c 
> b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> --- a/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> +++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -605,8 +606,10 @@ ti_bandgap_force_single_read(struct ti_bandgap *bgp, int 
> id)
>   u32 counter = 1000;
>   struct temp_sensor_registers *tsr;
>  
> - /* Select single conversion mode */
> - if (TI_BANDGAP_HAS(bgp, MODE_CONFIG))
> + /* Select continuous or single conversion mode */
> + if (TI_BANDGAP_HAS(bgp, CONT_MODE_ONLY))
> + RMW_BITS(bgp, id, bgap_mode_ctrl, mode_ctrl_mask, 1);
> + else if (TI_BANDGAP_HAS(bgp, MODE_CONFIG))
>   RMW_BITS(bgp, id, bgap_mode_ctrl, mode_ctrl_mask, 0);

Would not be better to:
if (TI_BANDGAP_HAS(bgp, MODE_CONFIG)) {
if (TI_BANDGAP_HAS(bgp, CONT_MODE_ONLY))
RMW_BITS(bgp, id, bgap_mode_ctrl, mode_ctrl_mask, 1);
else
RMW_BITS(bgp, id, bgap_mode_ctrl, mode_ctrl_mask, 0);
}

One can only switch to cont/single mode if the mode config is possible.

>  
>   /* Start of Conversion = 1 */
> @@ -619,6 +622,7 @@ ti_bandgap_force_single_read(struct ti_bandgap *bgp, int 
> id)
>   if (ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) &
>   tsr->bgap_eocz_mask)
>   break;
> + udelay(1);
>   }
>  
>   /* Start of Conversion = 0 */
> @@ -630,6 +634,7 @@ ti_bandgap_force_single_read(struct ti_bandgap *bgp, int 
> id)
>   if (!(ti_bandgap_readl(bgp, tsr->temp_sensor_ctrl) &
> tsr->bgap_eocz_mask))
>   break;
> + udelay(1);
>   }
>  
>   return 0;
> diff --git a/drivers/thermal/ti-soc-thermal/ti-bandgap.h 
> b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
> --- a/drivers/thermal/ti-soc-thermal/ti-bandgap.h
> +++ b/drivers/thermal/ti-soc-thermal/ti-bandgap.h
> @@ -280,6 +280,7 @@ struct ti_temp_sensor {
>   *   has Errata 814
>   * TI_BANDGAP_FEATURE_UNRELIABLE - used when the sensor readings are too
>   *   inaccurate.
> + * TI_BANDGAP_FEATURE_CONT_MODE_ONLY - used when single mode hangs the sensor
>   * TI_BANDGAP_HAS(b, f) - macro to check if a bandgap device is capable of a
>   *  specific feature (above) or not. Return non-zero, if yes.
>   */
> @@ -295,6 +296,7 @@ struct ti_temp_sensor {
>  #define TI_BANDGAP_FEATURE_HISTORY_BUFFERBIT(9)
>  #define TI_BANDGAP_FEATURE_E

ERROR: modpost: ".__warn_printk" undefined!

[kernel test robot]

Hi Christophe,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   f6e1ea19649216156576aeafa784e3b4cee45549
commit: 0a571b085ff6dadf946b248133533d3ba68f6e31 asm-generic: force inlining of 
get_order() to work around gcc10 poor decision
date:   2 weeks ago
config: powerpc-randconfig-r034-20201225 (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0a571b085ff6dadf946b248133533d3ba68f6e31
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 0a571b085ff6dadf946b248133533d3ba68f6e31
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=powerpc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>, old ones prefixed by <<):

ERROR: modpost: ".kmem_cache_free" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".fib_rules_register" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".lock_sock_nested" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".sk_stop_timer" [net/decnet/decnet.ko] undefined!
ERROR: modpost: "._raw_spin_lock_bh" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".__might_fault" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".sk_filter_trim_cap" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".finish_wait" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".__nla_parse" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".skb_trim" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".dev_get_by_index" [net/decnet/decnet.ko] undefined!
ERROR: modpost: "._raw_write_lock_bh" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".rtnl_is_locked" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".skb_push" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".neigh_parms_release" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".sprintf" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".dev_load" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".skb_put" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".sock_register" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".__dev_get_by_name" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".neigh_lookup" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".skb_realloc_headroom" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".__kmalloc" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".arch_local_irq_restore" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".wait_woken" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".dst_release_immediate" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".nla_put" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".neigh_parms_alloc" [net/decnet/decnet.ko] undefined!
ERROR: modpost: "._raw_spin_lock" [net/decnet/decnet.ko] undefined!
ERROR: modpost: "._raw_write_unlock" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".skb_unlink" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".sk_alloc" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".kmem_cache_create" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".__alloc_skb" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".nla_find" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".sk_free" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".dst_release" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".skb_dequeue" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".__raw_spin_lock_init" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".nla_reserve_nohdr" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".nla_strcmp" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".fib_default_rule_add" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".pskb_expand_head" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".send_sig" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".kvfree_call_rcu" [net/decnet/decnet.ko] undefined!
ERROR: modpost: "._raw_write_unlock_bh" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".neigh_for_each" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".skb_set_owner_w" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".proto_register" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".rtnl_put_cacheinfo" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".rtnl_notify" [net/decnet/decnet.ko] undefined!
ERROR: modpost: "._copy_from_iter_full" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".fib_rules_lookup" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".rtnl_lock" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".skb_queue_tail" [net/decnet/decnet.ko] undefined!
ERROR: modpost: ".skb_pu

Re: [PATCH 1/2] ASoC: wm_adsp: Only use __be32 for big-endian data

[Mark Brown]

On Wed, 30 Dec 2020 17:24:26 +, Richard Fitzgerald wrote:
> This fixes some minor cases where u32 or unsigned int types were used
> to store big-endian data, and __be32 types used to store both big-endian
> and cpu-endian data. This was producing sparse warnings.
> 
> Most cases resulted from using the same variable to hold the big-endian
> value and its converted cpu-endian value. These can be simply fixed by
> introducing another local variable, or avoiding storing the intermediate
> value back into the original variable.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/2] ASoC: wm_adsp: Only use __be32 for big-endian data
  commit: a0b653e89a3afd2a833f23589a83488fac842ddb
[2/2] ASoC: wm_adsp: Use snd_ctl_elem_type_t for control types
  commit: f6212e0ab3ff28d4e2e53a520496a052c241df39

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

Re: (subset) [PATCH 0/2] spi: rpc-if: Trivial fixes

[Mark Brown]

On Wed, 30 Dec 2020 14:57:06 +, Lad Prabhakar wrote:
> These patches are trivial fixes for rpc-if SPI driver.
> 
> Cheers,
> Prabhakar
> 
> Lad Prabhakar (2):
>   spi: rpc-if: Avoid use of C++ style comments
>   spi: rpc-if: Remove CONFIG_PM_SLEEP ifdefery
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[2/2] spi: rpc-if: Remove CONFIG_PM_SLEEP ifdefery
  commit: 9584fc95cadc0b86e5e01cefcff0ab2b31ee3a5b

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

Re: [PATCH] spi: Fix the clamping of spi->max_speed_hz

[Mark Brown]

On Wed, 16 Dec 2020 11:23:21 +0200, Tudor Ambarus wrote:
> If spi->controller->max_speed_hz is zero, a non-zero spi->max_speed_hz
> will be overwritten by zero. Make sure spi->controller->max_speed_hz
> is not zero when clamping spi->max_speed_hz.
> 
> Put the spi->controller->max_speed_hz non-zero check higher in the if,
> so that we avoid a superfluous init to zero when both spi->max_speed_hz
> and spi->controller->max_speed_hz are zero.

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git for-next

Thanks!

[1/1] spi: Fix the clamping of spi->max_speed_hz
  commit: 6820e812dafb4258bc14692f686eec5bde6fba86

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

Re: [PATCH] regmap: irq: do not allow setting irq bits during ack

[Mark Brown]

On Wed, Dec 30, 2020 at 08:37:17AM -0800, Tim Harvey wrote:

> It 'is' inverted ack because the device I have requires a '0' to be
> written to clear the interrupt instead of a '1'.

Right, yes - misremembered there.

> The chip I'm using has a status register where bit values of 1
> indicate an interrupt assertion and to clear it you write a 0 (where
> as the typical non-ack-invert case you write a 1 to clear). The chip
> I'm using also allows you to 'set' (by writing a 1) to bits that were
> not already set which would keep it from de-asserting it's interrupt.

> Honestly I thought the commit message was very clear. What exactly is
> your suggestion? It is of course confusing when talking about code
> that handles both ack invert and the normal case (let alone the new
> case of 'clear_ack').

First you need to write a commit message which explains what the change
is supposed to do.  Like I said it's things like talking about how "bits
are set" without specifying which bits you are talking about - which
bits?  You mean other bits in the status/ack register but especially
given all the talk about ack_invert in the commit message and the fact
that it is very unusual to be able to assert an interrupt by writing to
the status/ack register it's a bit of a jump to get there.  It could be
something to do with masking non-ack/status bits in the register, it
could be something to do with confusion about what inversion means, or
something else.  Something like your above explanation is much clearer
than what you wrote since it explains the unusual behaviour of your chip
which causes problems which makes it clear which bits you are talking
about.

The behaviour you are trying to implement here also needs to be opt in
since it will be harmful for other controllers due to it being racy, as
far as I can see with your controller there is no way to acknowledge a
single interrupt, we have to acknowledge them all since the only
sensible thing to write for any bit is an acknowledgement.  This means
that if handling an interrupt races with a different one being asserted
then the new interrupt will be acknowledged before it is seen as part of
acknowleding the original interrupt.  You could also express this as
doing a read/modify/write to clear just the bits that are asserted but
the effect is the same so probably an ack all mode would be easier.


signature.asc
Description: PGP signature

Re: [PATCH] ASoC: mediatek: add MTK_PMIC_WRAP dependency

[Mark Brown]

On Wed, 30 Dec 2020 16:43:34 +0100, Arnd Bergmann wrote:
> Randconfig builds often show harmless warnings like
> 
> WARNING: unmet direct dependencies detected for SND_SOC_MT6359
>   Depends on [n]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && 
> MTK_PMIC_WRAP [=n]
>   Selected by [y]:
>   - SND_SOC_MT8192_MT6359_RT1015_RT5682 [=y] && SOUND [=y] && !UML && SND 
> [=y] && SND_SOC [=y] && I2C [=y] && SND_SOC_MT8192 [=y]
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/1] ASoC: mediatek: add MTK_PMIC_WRAP dependency
  commit: c1cbbea9c4db41eb69a831d8b07da52e05b1d1e8

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

Re: [PATCH 2/2] spi: fix the divide by 0 error when calculating xfer waiting time

[Mark Brown]

On Thu, Dec 31, 2020 at 11:23:37AM +0800, Xu Yilun wrote:
> On Wed, Dec 30, 2020 at 01:46:44PM +, Mark Brown wrote:

> > > BTW, Could we keep the spi->max_speed_hz if no controller->max_speed_hz?
> > > Always clamp the spi->max_speed_hz to 0 makes no sense.

> > Right, that's the fix.

> Seems it still doesn't fix the case that neither controller nor client dev
> provides the non-zero max_speed_hz. Do you think the patch is still
> necessary?

Right, something like this would help if we genuinely have no idea.  We
probably shouldn't do it at validation stage which would be the other
thing since it might cause us to realy hurt performance on systems which
happen to have a sensible default in hardware but don't specify a
maximum - we might set too low a default speed for the actual transfer.
Please fix the coding style issue I mentioned and resubmit.


signature.asc
Description: PGP signature

WARNING in page_counter_cancel (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:f838f8d2 mfd: ab8500-debugfs: Remove extraneous seq_putc
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=163c244750
kernel config:  https://syzkaller.appspot.com/x/.config?x=7a43a64bad3fdb39
dashboard link: https://syzkaller.appspot.com/bug?extid=77ce5863039267003700
compiler:   gcc (GCC) 10.1.0-syz 20200507

Unfortunately, I don't have any reproducer for this issue yet.

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+77ce5863039267003...@syzkaller.appspotmail.com

[ cut here ]
WARNING: CPU: 2 PID: 22 at mm/page_counter.c:57 page_counter_cancel 
mm/page_counter.c:57 [inline]
WARNING: CPU: 2 PID: 22 at mm/page_counter.c:57 page_counter_cancel+0x56/0x70 
mm/page_counter.c:50
Modules linked in:
CPU: 2 PID: 22 Comm: ksoftirqd/2 Not tainted 5.10.0-syzkaller #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 
rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014
RIP: 0010:page_counter_cancel mm/page_counter.c:57 [inline]
RIP: 0010:page_counter_cancel+0x56/0x70 mm/page_counter.c:50
Code: 89 ef 48 89 c3 48 89 c6 e8 37 fd ff ff 31 ff 48 89 de e8 1d cc b8 ff 48 
85 db 78 09 5b 5d 41 5c e9 7f c5 b8 ff e8 7a c5 b8 ff <0f> 0b 5b 5d 41 5c e9 6f 
c5 b8 ff 0f 1f 44 00 00 66 2e 0f 1f 84 00
RSP: 0018:c9517328 EFLAGS: 00010046
RAX:  RBX: ffda RCX: 0100
RDX: 888010c146c0 RSI: 81b9b926 RDI: 0003
RBP: 8880146bc120 R08:  R09: 8880109d017f
R10: 81b9b913 R11:  R12: 0118
R13: 0200 R14: 8880146bc000 R15: 0002
FS:  () GS:88802cc0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 20008000 CR3: 6b808000 CR4: 00350ee0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 page_counter_uncharge+0x2e/0x60 mm/page_counter.c:156
 drain_stock+0xc9/0x2c0 mm/memcontrol.c:2314
 refill_stock+0x132/0x270 mm/memcontrol.c:2363
 __sk_mem_reduce_allocated+0x24d/0x550 net/core/sock.c:2711
 sk_mem_uncharge include/net/sock.h:1537 [inline]
 dfrag_uncharge net/mptcp/protocol.c:978 [inline]
 dfrag_clear+0x45e/0x540 net/mptcp/protocol.c:987
 __mptcp_clean_una+0x146/0xc60 net/mptcp/protocol.c:1011
 __mptcp_data_acked+0x88/0x290 net/mptcp/protocol.c:2909
 mptcp_incoming_options+0x917/0x1d20 net/mptcp/options.c:952
 tcp_data_queue+0x1665/0x4b10 net/ipv4/tcp_input.c:4943
 tcp_rcv_established+0x841/0x1eb0 net/ipv4/tcp_input.c:5886
 tcp_v4_do_rcv+0x5d1/0x870 net/ipv4/tcp_ipv4.c:1676
 tcp_v4_rcv+0x2d10/0x3750 net/ipv4/tcp_ipv4.c:2058
 ip_protocol_deliver_rcu+0x5c/0x8a0 net/ipv4/ip_input.c:204
 ip_local_deliver_finish+0x20a/0x370 net/ipv4/ip_input.c:231
 NF_HOOK include/linux/netfilter.h:301 [inline]
 NF_HOOK include/linux/netfilter.h:295 [inline]
 ip_local_deliver+0x1b3/0x200 net/ipv4/ip_input.c:252
 dst_input include/net/dst.h:447 [inline]
 ip_rcv_finish+0x1da/0x2f0 net/ipv4/ip_input.c:428
 NF_HOOK include/linux/netfilter.h:301 [inline]
 NF_HOOK include/linux/netfilter.h:295 [inline]
 ip_rcv+0xaa/0xd0 net/ipv4/ip_input.c:539
 __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5323
 __netif_receive_skb+0x27/0x1c0 net/core/dev.c:5437
 process_backlog+0x232/0x6c0 net/core/dev.c:6327
 napi_poll net/core/dev.c:6805 [inline]
 net_rx_action+0x461/0xe10 net/core/dev.c:6888
 __do_softirq+0x2a5/0x9f7 kernel/softirq.c:343
 run_ksoftirqd kernel/softirq.c:650 [inline]
 run_ksoftirqd+0x2d/0x50 kernel/softirq.c:642
 smpboot_thread_fn+0x655/0x9e0 kernel/smpboot.c:165
 kthread+0x3b1/0x4a0 kernel/kthread.c:292
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

Re: [PATCH 2/4] net: sfp: allow to use also SFP modules which are detected as SFF

[Pali Rohár]

On Wednesday 30 December 2020 19:12:40 Russell King - ARM Linux admin wrote:
> On Wed, Dec 30, 2020 at 06:27:07PM +0100, Marek Behún wrote:
> > On Wed, 30 Dec 2020 18:06:52 +0100
> > Pali Rohár  wrote:
> > 
> > >   if (!sfp->type->module_supported(&id) &&
> > >   (memcmp(id.base.vendor_name, "UBNT", 16) ||
> > >memcmp(id.base.vendor_pn, "UF-INSTANT  ", 16)))
> > 
> > I would rather add a quirk member (bitfield) to the sfp structure and do
> > something like this
> > 
> > if (!sfp->type->module_supported(&id) &&
> > !(sfp->quirks & SFP_QUIRK_BAD_PHYS_ID))
> > 
> > or maybe put this check into the module_supported method.
> 
> Sorry, definitely not. If you've ever looked at the SDHCI driver with
> its multiple "quirks" bitfields, doing this is a recipe for creating
> a very horrid hard to understand mess.
> 
> What you suggest just results in yet more complexity.

Should I rather put this vendor name/pn check into the
sfp_module_supported() function?

static bool sfp_module_supported(const struct sfp_eeprom_id *id)
{
if (id->base.phys_id == SFF8024_ID_SFP &&
id->base.phys_ext_id == SFP_PHYS_EXT_ID_SFP)
return true;

if (id->base.phys_id == SFF8024_ID_SFF_8472 &&
id->base.phys_ext_id == SFP_PHYS_EXT_ID_SFP &&
!memcmp(id->base.vendor_name, "UBNT", 16) &&
!memcmp(id->base.vendor_pn, "UF-INSTANT  ", 16))
return true;

return false;
}

[PATCH v6 0/2] media: i2c: OV5648 image sensor support

[Paul Kocialkowski]

This series adds support for the OV5648 image sensor,
as a V4L2 subdev driver.

Changes since v5:
- Removed extra tailing ret checks;
- Fixed variables names in macros using container_of;
- Set ctrls flags after handler error check;
- Removed useless ret initializations and gotos;
- Removed call to v4l2_device_unregister_subdev;

Changes since v4:
- Squashed tailing function calls in return;
- Added Kconfig depend on PM since it's not optional;
- Reordered runtime PM in init;
- Reworked runtime PM order and added ctrls handler free in exit.

Changes since v3:
- Removed mipi_clk_rate variable that skipped through.

Changes since v2:
- Added link-frequencies endpoint property support;
- Used NULL ctrl ops for pixel rate and link freq;
- Extra cosmetic changes.

Changes since v1:
- Used runtime pm;
- Used assigned-clock-rate;
- Removed clock name;
- Returned closest size in set_fmt;
- Removed unneeded references to v4l2 controls;
- Removed i2c device table;
- Dual-licensed bindings;
- Used SPDX tags.

Paul Kocialkowski (2):
  dt-bindings: media: i2c: Add OV5648 bindings documentation
  media: i2c: Add support for the OV5648 image sensor

 .../bindings/media/i2c/ovti,ov5648.yaml   |  115 +
 drivers/media/i2c/Kconfig |   13 +
 drivers/media/i2c/Makefile|1 +
 drivers/media/i2c/ov5648.c| 2624 +
 4 files changed, 2753 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml
 create mode 100644 drivers/media/i2c/ov5648.c

-- 
2.29.2

[PATCH v6 2/2] media: i2c: Add support for the OV5648 image sensor

[Paul Kocialkowski]

The OV5648 is a 5 Mpx CMOS image sensor, connected via MIPI CSI-2
in a one or two lane configuration.

Most of the features of the hardware are supported, including:
- Auto and manual exposition/gain
- Auto and manual white balance
- Horizontal and vertical flip
- Test patterns

But the following are still missing:
- Debanding, based on power source frequency;
- Exposition setting correlated to time units.

Signed-off-by: Paul Kocialkowski 
---
 drivers/media/i2c/Kconfig  |   13 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/ov5648.c | 2624 
 3 files changed, 2638 insertions(+)
 create mode 100644 drivers/media/i2c/ov5648.c

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 878f66ef2719..c0470a8b9a80 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -922,6 +922,19 @@ config VIDEO_OV5647
  To compile this driver as a module, choose M here: the
  module will be called ov5647.
 
+config VIDEO_OV5648
+   tristate "OmniVision OV5648 sensor support"
+   depends on I2C && PM && VIDEO_V4L2
+   select MEDIA_CONTROLLER
+   select VIDEO_V4L2_SUBDEV_API
+   select V4L2_FWNODE
+   help
+ This is a Video4Linux2 sensor driver for the OmniVision
+ OV5648 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov5648.
+
 config VIDEO_OV6650
tristate "OmniVision OV6650 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index f0a77473979d..15d4d6382582 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_VIDEO_OV2740) += ov2740.o
 obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
 obj-$(CONFIG_VIDEO_OV5645) += ov5645.o
 obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
+obj-$(CONFIG_VIDEO_OV5648) += ov5648.o
 obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
 obj-$(CONFIG_VIDEO_OV5675) += ov5675.o
 obj-$(CONFIG_VIDEO_OV5695) += ov5695.o
diff --git a/drivers/media/i2c/ov5648.c b/drivers/media/i2c/ov5648.c
new file mode 100644
index ..8c3dc483f14e
--- /dev/null
+++ b/drivers/media/i2c/ov5648.c
@@ -0,0 +1,2624 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2020 Bootlin
+ * Author: Paul Kocialkowski 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Clock rate */
+
+#define OV5648_XVCLK_RATE  2400
+
+/* Register definitions */
+
+/* System */
+
+#define OV5648_SW_STANDBY_REG  0x100
+#define OV5648_SW_STANDBY_STREAM_ONBIT(0)
+
+#define OV5648_SW_RESET_REG0x103
+#define OV5648_SW_RESET_RESET  BIT(0)
+
+#define OV5648_PAD_OEN0_REG0x3000
+#define OV5648_PAD_OEN1_REG0x3001
+#define OV5648_PAD_OEN2_REG0x3002
+#define OV5648_PAD_OUT0_REG0x3008
+#define OV5648_PAD_OUT1_REG0x3009
+
+#define OV5648_CHIP_ID_H_REG   0x300a
+#define OV5648_CHIP_ID_H_VALUE 0x56
+#define OV5648_CHIP_ID_L_REG   0x300b
+#define OV5648_CHIP_ID_L_VALUE 0x48
+
+#define OV5648_PAD_OUT2_REG0x300d
+#define OV5648_PAD_SEL0_REG0x300e
+#define OV5648_PAD_SEL1_REG0x300f
+#define OV5648_PAD_SEL2_REG0x3010
+#define OV5648_PAD_PK_REG  0x3011
+#define OV5648_PAD_PK_PD_DATO_EN   BIT(7)
+#define OV5648_PAD_PK_DRIVE_STRENGTH_1X(0 << 5)
+#define OV5648_PAD_PK_DRIVE_STRENGTH_2X(2 << 5)
+#define OV5648_PAD_PK_FREX_N   BIT(1)
+
+#define OV5648_A_PWC_PK_O0_REG 0x3013
+#define OV5648_A_PWC_PK_O0_BP_REGULATOR_N  BIT(3)
+#define OV5648_A_PWC_PK_O1_REG 0x3014
+
+#define OV5648_MIPI_PHY0_REG   0x3016
+#define OV5648_MIPI_PHY1_REG   0x3017
+#define OV5648_MIPI_SC_CTRL0_REG   0x3018
+#define OV5648_MIPI_SC_CTRL0_MIPI_LANES(v) (((v) << 5) & GENMASK(7, 5))
+#define OV5648_MIPI_SC_CTRL0_PHY_HS_TX_PD  BIT(4)
+#define OV5648_MIPI_SC_CTRL0_PHY_LP_RX_PD  BIT(3)
+#define OV5648_MIPI_SC_CTRL0_MIPI_EN   BIT(2)
+#define OV5648_MIPI_SC_CTRL0_MIPI_SUSP BIT(1)
+#define OV5648_MIPI_SC_CTRL0_LANE_DIS_OP   BIT(0)
+#define OV5648_MIPI_SC_CTRL1_REG   0x3019
+#define OV5648_MISC_CTRL0_REG  0x3021
+#define OV5648_MIPI_SC_CTRL2_REG   0x3022
+#define OV5648_SUB_ID_REG  0x302a
+
+#define OV5648_PLL_CTRL0_REG   0x3034
+#define OV5648_PLL_CTRL0_PLL_CHARGE_PUMP(v)(((v) << 4) & GENMASK(6, 4))
+#define OV5648_PLL_CTRL0_BITS(v)   ((v) & GENMASK(3, 0))
+#define OV5648_PLL_CT

[PATCH v6 1/2] dt-bindings: media: i2c: Add OV5648 bindings documentation

[Paul Kocialkowski]

This introduces YAML bindings documentation for the OV5648
image sensor.

Signed-off-by: Paul Kocialkowski 
Reviewed-by: Rob Herring 
---
 .../bindings/media/i2c/ovti,ov5648.yaml   | 115 ++
 1 file changed, 115 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml

diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml 
b/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml
new file mode 100644
index ..f8783f77cc54
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml
@@ -0,0 +1,115 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov5648.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OmniVision OV5648 Image Sensor Device Tree Bindings
+
+maintainers:
+  - Paul Kocialkowski 
+
+properties:
+  compatible:
+const: ovti,ov5648
+
+  reg:
+maxItems: 1
+
+  clocks:
+items:
+  - description: XVCLK Clock
+
+  assigned-clocks:
+maxItems: 1
+
+  assigned-clock-rates:
+maxItems: 1
+
+  dvdd-supply:
+description: Digital Domain Power Supply
+
+  avdd-supply:
+description: Analog Domain Power Supply (internal AVDD is used if missing)
+
+  dovdd-supply:
+description: I/O Domain Power Supply
+
+  powerdown-gpios:
+maxItems: 1
+description: Power Down Pin GPIO Control (active low)
+
+  reset-gpios:
+maxItems: 1
+description: Reset Pin GPIO Control (active low)
+
+  port:
+type: object
+description: MIPI CSI-2 transmitter port
+
+properties:
+  endpoint:
+type: object
+
+properties:
+  remote-endpoint: true
+
+  link-frequencies:
+$ref: /schemas/types.yaml#/definitions/uint64-array
+description: Allowed MIPI CSI-2 link frequencies
+
+  data-lanes:
+minItems: 1
+maxItems: 2
+
+required:
+  - data-lanes
+  - link-frequencies
+  - remote-endpoint
+
+required:
+  - endpoint
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - assigned-clocks
+  - assigned-clock-rates
+  - dvdd-supply
+  - dovdd-supply
+  - port
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+
+i2c0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+ov5648: camera@36 {
+compatible = "ovti,ov5648";
+reg = <0x36>;
+
+dvdd-supply = <&ov5648_dvdd>;
+avdd-supply = <&ov5648_avdd>;
+dovdd-supply = <&ov5648_dovdd>;
+clocks = <&ov5648_xvclk 0>;
+assigned-clocks = <&ov5648_xvclk 0>;
+assigned-clock-rates = <2400>;
+
+
+ov5648_out: port {
+ov5648_out_mipi_csi2: endpoint {
+data-lanes = <1 2>;
+link-frequencies = /bits/ 64 <21000 16800>;
+
+remote-endpoint = <&mipi_csi2_in_ov5648>;
+};
+};
+};
+};
-- 
2.29.2

[PATCH] Revert "clk: imx: fix composite peripheral flags"

[Martin Kepplinger]

This reverts commit 936c383673b9e3007432f17140ac62de53d87db9.

It breaks clock reparenting via devfreq on the imx8mq used in the
Librem 5 phone. When switching dram frequency (which worked before)
the system now hangs after this where the dram_apb clock cannot be
set:

[  129.391755] imx8m-ddrc-devfreq 3d40.memory-controller: failed to
set dram_apb parent: -16
[  129.391959] imx8m-ddrc-devfreq 3d40.memory-controller: ddrc
failed freq switch to 2500 from 8: error -16. now at 2500
[  129.406133] imx8m-ddrc-devfreq 3d40.memory-controller: failed to
update frequency from PM QoS (-16)

Note that on the Librem 5 devkit that uses a different revision of the
imx8mq SoC, the added flag does *not* break said clock reparenting so
there might be subtle differences here.

Signed-off-by: Martin Kepplinger 
---
 drivers/clk/imx/clk-composite-8m.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/clk/imx/clk-composite-8m.c 
b/drivers/clk/imx/clk-composite-8m.c
index 2c309e3dc8e3..78fb7e52a42a 100644
--- a/drivers/clk/imx/clk-composite-8m.c
+++ b/drivers/clk/imx/clk-composite-8m.c
@@ -216,7 +216,6 @@ struct clk_hw *imx8m_clk_hw_composite_flags(const char 
*name,
div->width = PCG_PREDIV_WIDTH;
divider_ops = &imx8m_clk_composite_divider_ops;
mux_ops = &clk_mux_ops;
-   flags |= CLK_SET_PARENT_GATE;
}
 
div->lock = &imx_ccm_lock;
-- 
2.20.1

Re: [PATCH RESEND v2 2/2] Add support for Realtek RTL838x/RTL839x SoC SPI controllers

[Lukas Wunner]

On Wed, Dec 30, 2020 at 12:19:04AM +0100, Bert Vermeulen wrote:
> +static inline void wait_ready(struct rtspi *rtspi)
> +{
> + while (!(readl(REG(RTL8380_SPI_SFCSR)) & RTL8380_SPI_SFCSR_RDY))
> + ;
> +}

I'd suggest calling cpu_relax() in the loop's body.


> + err = devm_spi_register_controller(&pdev->dev, ctrl);

Since you're invoking devm_spi_register_controller() on probe,
the controller must not be unregistered explicitly on remove.
So the ->remove hook can be dropped altogether:

> +static int realtek_spi_remove(struct platform_device *pdev)
> +{
> + struct spi_controller *ctrl = platform_get_drvdata(pdev);
> +
> + spi_unregister_controller(ctrl);
> +
> + return 0;
> +}
[...]
> + .remove = realtek_spi_remove,

The ->probe hook otherwise LGTM.

Thanks,

Lukas

[PATCH v7 1/2] dt-bindings: media: i2c: Add OV5648 bindings documentation

[Paul Kocialkowski]

This introduces YAML bindings documentation for the OV5648
image sensor.

Signed-off-by: Paul Kocialkowski 
Reviewed-by: Rob Herring 
---
 .../bindings/media/i2c/ovti,ov5648.yaml   | 115 ++
 1 file changed, 115 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml

diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml 
b/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml
new file mode 100644
index ..f8783f77cc54
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml
@@ -0,0 +1,115 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov5648.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OmniVision OV5648 Image Sensor Device Tree Bindings
+
+maintainers:
+  - Paul Kocialkowski 
+
+properties:
+  compatible:
+const: ovti,ov5648
+
+  reg:
+maxItems: 1
+
+  clocks:
+items:
+  - description: XVCLK Clock
+
+  assigned-clocks:
+maxItems: 1
+
+  assigned-clock-rates:
+maxItems: 1
+
+  dvdd-supply:
+description: Digital Domain Power Supply
+
+  avdd-supply:
+description: Analog Domain Power Supply (internal AVDD is used if missing)
+
+  dovdd-supply:
+description: I/O Domain Power Supply
+
+  powerdown-gpios:
+maxItems: 1
+description: Power Down Pin GPIO Control (active low)
+
+  reset-gpios:
+maxItems: 1
+description: Reset Pin GPIO Control (active low)
+
+  port:
+type: object
+description: MIPI CSI-2 transmitter port
+
+properties:
+  endpoint:
+type: object
+
+properties:
+  remote-endpoint: true
+
+  link-frequencies:
+$ref: /schemas/types.yaml#/definitions/uint64-array
+description: Allowed MIPI CSI-2 link frequencies
+
+  data-lanes:
+minItems: 1
+maxItems: 2
+
+required:
+  - data-lanes
+  - link-frequencies
+  - remote-endpoint
+
+required:
+  - endpoint
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - assigned-clocks
+  - assigned-clock-rates
+  - dvdd-supply
+  - dovdd-supply
+  - port
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+
+i2c0 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+ov5648: camera@36 {
+compatible = "ovti,ov5648";
+reg = <0x36>;
+
+dvdd-supply = <&ov5648_dvdd>;
+avdd-supply = <&ov5648_avdd>;
+dovdd-supply = <&ov5648_dovdd>;
+clocks = <&ov5648_xvclk 0>;
+assigned-clocks = <&ov5648_xvclk 0>;
+assigned-clock-rates = <2400>;
+
+
+ov5648_out: port {
+ov5648_out_mipi_csi2: endpoint {
+data-lanes = <1 2>;
+link-frequencies = /bits/ 64 <21000 16800>;
+
+remote-endpoint = <&mipi_csi2_in_ov5648>;
+};
+};
+};
+};
-- 
2.29.2

[PATCH v7 0/2] media: i2c: OV5648 image sensor support

[Paul Kocialkowski]

This series adds support for the OV5648 image sensor,
as a V4L2 subdev driver.

Changes since v6:
- Removed unused ret declaration that caused a build warning.

Changes since v5:
- Removed extra tailing ret checks;
- Fixed variables names in macros using container_of;
- Set ctrls flags after handler error check;
- Removed useless ret initializations and gotos;
- Removed call to v4l2_device_unregister_subdev;

Changes since v4:
- Squashed tailing function calls in return;
- Added Kconfig depend on PM since it's not optional;
- Reordered runtime PM in init;
- Reworked runtime PM order and added ctrls handler free in exit.

Changes since v3:
- Removed mipi_clk_rate variable that skipped through.

Changes since v2:
- Added link-frequencies endpoint property support;
- Used NULL ctrl ops for pixel rate and link freq;
- Extra cosmetic changes.

Changes since v1:
- Used runtime pm;
- Used assigned-clock-rate;
- Removed clock name;
- Returned closest size in set_fmt;
- Removed unneeded references to v4l2 controls;
- Removed i2c device table;
- Dual-licensed bindings;
- Used SPDX tags.

Paul Kocialkowski (2):
  dt-bindings: media: i2c: Add OV5648 bindings documentation
  media: i2c: Add support for the OV5648 image sensor

 .../bindings/media/i2c/ovti,ov5648.yaml   |  115 +
 drivers/media/i2c/Kconfig |   13 +
 drivers/media/i2c/Makefile|1 +
 drivers/media/i2c/ov5648.c| 2623 +
 4 files changed, 2752 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml
 create mode 100644 drivers/media/i2c/ov5648.c

-- 
2.29.2

[PATCH v7 2/2] media: i2c: Add support for the OV5648 image sensor

[Paul Kocialkowski]

The OV5648 is a 5 Mpx CMOS image sensor, connected via MIPI CSI-2
in a one or two lane configuration.

Most of the features of the hardware are supported, including:
- Auto and manual exposition/gain
- Auto and manual white balance
- Horizontal and vertical flip
- Test patterns

But the following are still missing:
- Debanding, based on power source frequency;
- Exposition setting correlated to time units.

Signed-off-by: Paul Kocialkowski 
---
 drivers/media/i2c/Kconfig  |   13 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/ov5648.c | 2623 
 3 files changed, 2637 insertions(+)
 create mode 100644 drivers/media/i2c/ov5648.c

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 878f66ef2719..c0470a8b9a80 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -922,6 +922,19 @@ config VIDEO_OV5647
  To compile this driver as a module, choose M here: the
  module will be called ov5647.
 
+config VIDEO_OV5648
+   tristate "OmniVision OV5648 sensor support"
+   depends on I2C && PM && VIDEO_V4L2
+   select MEDIA_CONTROLLER
+   select VIDEO_V4L2_SUBDEV_API
+   select V4L2_FWNODE
+   help
+ This is a Video4Linux2 sensor driver for the OmniVision
+ OV5648 camera.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov5648.
+
 config VIDEO_OV6650
tristate "OmniVision OV6650 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index f0a77473979d..15d4d6382582 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -71,6 +71,7 @@ obj-$(CONFIG_VIDEO_OV2740) += ov2740.o
 obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
 obj-$(CONFIG_VIDEO_OV5645) += ov5645.o
 obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
+obj-$(CONFIG_VIDEO_OV5648) += ov5648.o
 obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
 obj-$(CONFIG_VIDEO_OV5675) += ov5675.o
 obj-$(CONFIG_VIDEO_OV5695) += ov5695.o
diff --git a/drivers/media/i2c/ov5648.c b/drivers/media/i2c/ov5648.c
new file mode 100644
index ..609aa67b54ce
--- /dev/null
+++ b/drivers/media/i2c/ov5648.c
@@ -0,0 +1,2623 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2020 Bootlin
+ * Author: Paul Kocialkowski 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Clock rate */
+
+#define OV5648_XVCLK_RATE  2400
+
+/* Register definitions */
+
+/* System */
+
+#define OV5648_SW_STANDBY_REG  0x100
+#define OV5648_SW_STANDBY_STREAM_ONBIT(0)
+
+#define OV5648_SW_RESET_REG0x103
+#define OV5648_SW_RESET_RESET  BIT(0)
+
+#define OV5648_PAD_OEN0_REG0x3000
+#define OV5648_PAD_OEN1_REG0x3001
+#define OV5648_PAD_OEN2_REG0x3002
+#define OV5648_PAD_OUT0_REG0x3008
+#define OV5648_PAD_OUT1_REG0x3009
+
+#define OV5648_CHIP_ID_H_REG   0x300a
+#define OV5648_CHIP_ID_H_VALUE 0x56
+#define OV5648_CHIP_ID_L_REG   0x300b
+#define OV5648_CHIP_ID_L_VALUE 0x48
+
+#define OV5648_PAD_OUT2_REG0x300d
+#define OV5648_PAD_SEL0_REG0x300e
+#define OV5648_PAD_SEL1_REG0x300f
+#define OV5648_PAD_SEL2_REG0x3010
+#define OV5648_PAD_PK_REG  0x3011
+#define OV5648_PAD_PK_PD_DATO_EN   BIT(7)
+#define OV5648_PAD_PK_DRIVE_STRENGTH_1X(0 << 5)
+#define OV5648_PAD_PK_DRIVE_STRENGTH_2X(2 << 5)
+#define OV5648_PAD_PK_FREX_N   BIT(1)
+
+#define OV5648_A_PWC_PK_O0_REG 0x3013
+#define OV5648_A_PWC_PK_O0_BP_REGULATOR_N  BIT(3)
+#define OV5648_A_PWC_PK_O1_REG 0x3014
+
+#define OV5648_MIPI_PHY0_REG   0x3016
+#define OV5648_MIPI_PHY1_REG   0x3017
+#define OV5648_MIPI_SC_CTRL0_REG   0x3018
+#define OV5648_MIPI_SC_CTRL0_MIPI_LANES(v) (((v) << 5) & GENMASK(7, 5))
+#define OV5648_MIPI_SC_CTRL0_PHY_HS_TX_PD  BIT(4)
+#define OV5648_MIPI_SC_CTRL0_PHY_LP_RX_PD  BIT(3)
+#define OV5648_MIPI_SC_CTRL0_MIPI_EN   BIT(2)
+#define OV5648_MIPI_SC_CTRL0_MIPI_SUSP BIT(1)
+#define OV5648_MIPI_SC_CTRL0_LANE_DIS_OP   BIT(0)
+#define OV5648_MIPI_SC_CTRL1_REG   0x3019
+#define OV5648_MISC_CTRL0_REG  0x3021
+#define OV5648_MIPI_SC_CTRL2_REG   0x3022
+#define OV5648_SUB_ID_REG  0x302a
+
+#define OV5648_PLL_CTRL0_REG   0x3034
+#define OV5648_PLL_CTRL0_PLL_CHARGE_PUMP(v)(((v) << 4) & GENMASK(6, 4))
+#define OV5648_PLL_CTRL0_BITS(v)   ((v) & GENMASK(3, 0))
+#define OV5648_PLL_CT

[PATCH v4 0/3] media: i2c: OV8865 image sensor support

[Paul Kocialkowski]

This series adds support for the OV8865 image sensor, as a V4L2 subdev
driver. Although an initial series was submitted by Kévin L'hôpital some
weeks ago, this version is significantly new and should be considered a
new series.

The final patch (not for merge) shows how to enable the OV8865 on the
Banana Pi Camera Board v2 with the Banana Pi M3.

Changes since v3:
- Fixed error label goto after runtime pm calls in probe;
- Fixed variables names in macros using container_of;
- Set ctrls flags after handler error check;
- Removed useless ret initializations and gotos;
- Removed call to v4l2_device_unregister_subdev.

Changes since v2:
- Added link-frequencies endpoint property support;
- Marked avdd-supply as non-optional (no internal regulator);
- Used NULL ctrl ops for pixel rate and link freq;
- Extra cosmetic changes.

Changes since v1:
- Used runtime pm;
- Used assigned-clock-rate;
- Removed clock name;
- Returned closest size in set_fmt;
- Removed unneeded references to v4l2 controls;
- Removed unneeded structure packing attribute;
- Removed i2c device table;
- Dual-licensed bindings;
- Used SPDX tags.

Cheers,

Paul

Kévin L'hôpital (1):
  ARM: dts: sun8i: a83t: bananapi-m3: Enable MIPI CSI-2 with OV8865

Paul Kocialkowski (2):
  dt-bindings: media: i2c: Add OV8865 bindings documentation
  media: i2c: Add support for the OV8865 image sensor

 .../bindings/media/i2c/ovti,ov8865.yaml   |  124 +
 arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts  |  102 +
 drivers/media/i2c/Kconfig |   13 +
 drivers/media/i2c/Makefile|1 +
 drivers/media/i2c/ov8865.c| 2972 +
 5 files changed, 3212 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml
 create mode 100644 drivers/media/i2c/ov8865.c

-- 
2.29.2

[PATCH v4 1/3] dt-bindings: media: i2c: Add OV8865 bindings documentation

[Paul Kocialkowski]

This introduces YAML bindings documentation for the OV8865
image sensor.

Co-developed-by: Kévin L'hôpital 
Signed-off-by: Kévin L'hôpital 
Signed-off-by: Paul Kocialkowski 
Reviewed-by: Rob Herring 
---
 .../bindings/media/i2c/ovti,ov8865.yaml   | 124 ++
 1 file changed, 124 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml

diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml 
b/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml
new file mode 100644
index ..c0ba28aa30c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml
@@ -0,0 +1,124 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov8865.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: OmniVision OV8865 Image Sensor Device Tree Bindings
+
+maintainers:
+  - Paul Kocialkowski 
+
+properties:
+  compatible:
+const: ovti,ov8865
+
+  reg:
+maxItems: 1
+
+  clocks:
+items:
+  - description: EXTCLK Clock
+
+  assigned-clocks:
+maxItems: 1
+
+  assigned-clock-rates:
+maxItems: 1
+
+  dvdd-supply:
+description: Digital Domain Power Supply
+
+  avdd-supply:
+description: Analog Domain Power Supply
+
+  dovdd-supply:
+description: I/O Domain Power Supply
+
+  powerdown-gpios:
+maxItems: 1
+description: Power Down Pin GPIO Control (active low)
+
+  reset-gpios:
+maxItems: 1
+description: Reset Pin GPIO Control (active low)
+
+  port:
+type: object
+description: MIPI CSI-2 transmitter port
+
+properties:
+  endpoint:
+type: object
+
+properties:
+  remote-endpoint: true
+
+  link-frequencies:
+$ref: /schemas/types.yaml#/definitions/uint64-array
+description: Allowed MIPI CSI-2 link frequencies
+
+  data-lanes:
+minItems: 1
+maxItems: 4
+
+required:
+  - data-lanes
+  - link-frequencies
+  - remote-endpoint
+
+required:
+  - endpoint
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - assigned-clocks
+  - assigned-clock-rates
+  - dvdd-supply
+  - avdd-supply
+  - dovdd-supply
+  - port
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+
+i2c2 {
+#address-cells = <1>;
+#size-cells = <0>;
+
+ov8865: camera@36 {
+compatible = "ovti,ov8865";
+reg = <0x36>;
+
+pinctrl-names = "default";
+pinctrl-0 = <&csi_mclk_pin>;
+
+clocks = <&ccu CLK_CSI_MCLK>;
+assigned-clocks = <&ccu CLK_CSI_MCLK>;
+assigned-clock-rates = <2400>;
+
+avdd-supply = <®_ov8865_avdd>;
+dovdd-supply = <®_ov8865_dovdd>;
+dvdd-supply = <®_ov8865_dvdd>;
+
+powerdown-gpios = <&pio 4 17 GPIO_ACTIVE_LOW>; /* PE17 */
+reset-gpios = <&pio 4 16 GPIO_ACTIVE_LOW>; /* PE16 */
+
+port {
+ov8865_out_mipi_csi2: endpoint {
+data-lanes = <1 2 3 4>;
+link-frequencies = /bits/ 64 <36000>;
+
+remote-endpoint = <&mipi_csi2_in_ov8865>;
+};
+};
+};
+};
+
+...
-- 
2.29.2

[PATCH NOT FOR MERGE v4 3/3] ARM: dts: sun8i: a83t: bananapi-m3: Enable MIPI CSI-2 with OV8865

[Paul Kocialkowski]

From: Kévin L'hôpital 

The Bananapi M3 supports a camera module which includes an OV8865 sensor
connected via the parallel CSI interface and an OV8865 sensor connected
via MIPI CSI-2.

The I2C2 bus is shared by the two sensors as well as the (active-low)
reset signal, but each sensor has it own shutdown line.

Signed-off-by: Kévin L'hôpital 
Signed-off-by: Paul Kocialkowski 
---
 arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 102 +++
 1 file changed, 102 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts 
b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
index 431f70234d36..bebe843a069b 100644
--- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
@@ -85,6 +85,30 @@ green {
};
};
 
+   reg_ov8865_avdd: ov8865-avdd {
+   compatible = "regulator-fixed";
+   regulator-name = "ov8865-avdd";
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   vin-supply = <®_dldo4>;
+   };
+
+   reg_ov8865_dovdd: ov8865-dovdd {
+   compatible = "regulator-fixed";
+   regulator-name = "ov8865-dovdd";
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   vin-supply = <®_dldo4>;
+   };
+
+   reg_ov8865_dvdd: ov8865-dvdd {
+   compatible = "regulator-fixed";
+   regulator-name = "ov8865-dvdd";
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <120>;
+   vin-supply = <®_eldo1>;
+   };
+
reg_usb1_vbus: reg-usb1-vbus {
compatible = "regulator-fixed";
regulator-name = "usb1-vbus";
@@ -115,6 +139,23 @@ &cpu100 {
cpu-supply = <®_dcdc3>;
 };
 
+&csi {
+   status = "okay";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   reg = <1>;
+
+   csi_in_mipi_csi2: endpoint {
+   remote-endpoint = <&mipi_csi2_out_csi>;
+   };
+   };
+   };
+};
+
 &de {
status = "okay";
 };
@@ -147,6 +188,36 @@ hdmi_out_con: endpoint {
};
 };
 
+&i2c2 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&i2c2_pe_pins>;
+   status = "okay";
+
+   ov8865: camera@36 {
+   compatible = "ovti,ov8865";
+   reg = <0x36>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&csi_mclk_pin>;
+   clocks = <&ccu CLK_CSI_MCLK>;
+   assigned-clocks = <&ccu CLK_CSI_MCLK>;
+   assigned-clock-rates = <2400>;
+   avdd-supply = <®_ov8865_avdd>;
+   dovdd-supply = <®_ov8865_dovdd>;
+   dvdd-supply = <®_ov8865_dvdd>;
+   powerdown-gpios = <&pio 4 17 GPIO_ACTIVE_LOW>; /* PE17 */
+   reset-gpios = <&pio 4 16 GPIO_ACTIVE_LOW>; /* PE16 */
+
+   port {
+   ov8865_out_mipi_csi2: endpoint {
+   data-lanes = <1 2 3 4>;
+   link-frequencies = /bits/ 64 <36000>;
+
+   remote-endpoint = <&mipi_csi2_in_ov8865>;
+   };
+   };
+   };
+};
+
 &mdio {
rgmii_phy: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
@@ -154,6 +225,24 @@ rgmii_phy: ethernet-phy@1 {
};
 };
 
+&mipi_csi2 {
+   status = "okay";
+};
+
+&mipi_csi2_in {
+   mipi_csi2_in_ov8865: endpoint {
+   data-lanes = <1 2 3 4>;
+
+   remote-endpoint = <&ov8865_out_mipi_csi2>;
+   };
+};
+
+&mipi_csi2_out {
+   mipi_csi2_out_csi: endpoint {
+   remote-endpoint = <&csi_in_mipi_csi2>;
+   };
+};
+
 &mmc0 {
pinctrl-names = "default";
pinctrl-0 = <&mmc0_pins>;
@@ -327,11 +416,24 @@ ®_dldo3 {
regulator-name = "vcc-pd";
 };
 
+®_dldo4 {
+   regulator-always-on;
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   regulator-name = "avdd-csi";
+};
+
 ®_drivevbus {
regulator-name = "usb0-vbus";
status = "okay";
 };
 
+®_eldo1 {
+   regulator-min-microvolt = <120>;
+   regulator-max-microvolt = <120>;
+   regulator-name = "dvdd-csi-r";
+};
+
 ®_fldo1 {
regulator-min-microvolt = <108>;
regulator-max-microvolt = <132>;
-- 
2.29.2

[PATCH v4 2/3] media: i2c: Add support for the OV8865 image sensor

[Paul Kocialkowski]

The OV8865 is a 8 Mpx CMOS image sensor producing 3264x2448 at 30 fps.
Other modes (including some with sub-sampling) are available too.
It outputs 10-bit bayer CFA data through a MIPI CSI-2 interface with
up to 4 lanes supported.

Some register initialisation sequences are still needed for this driver,
as they cover registers for which no documentation is available.

This work is based on the first version of the driver submitted by
Kévin L'hôpital, which was adapted to mainline from the Allwinner BSP.
This version is a rewrite of the first version that matches the structure
of the OV5648 driver, with explicit PLL configuration, all the necessary
mode-specific fields, associatied registers and reduced static sequences.

It was tested with the Banana Pi Camera Board v3 and the Banana Pi M3.

Co-developed-by: Kévin L'hôpital 
Signed-off-by: Kévin L'hôpital 
Signed-off-by: Paul Kocialkowski 
---
 drivers/media/i2c/Kconfig  |   13 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/ov8865.c | 2972 
 3 files changed, 2986 insertions(+)
 create mode 100644 drivers/media/i2c/ov8865.c

diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index c0470a8b9a80..6bc505c1f171 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -1046,6 +1046,19 @@ config VIDEO_OV8856
  To compile this driver as a module, choose M here: the
  module will be called ov8856.
 
+config VIDEO_OV8865
+   tristate "OmniVision OV8865 sensor support"
+   depends on I2C && PM && VIDEO_V4L2
+   select MEDIA_CONTROLLER
+   select VIDEO_V4L2_SUBDEV_API
+   select V4L2_FWNODE
+   help
+ This is a Video4Linux2 sensor driver for OmniVision
+ OV8865 camera sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ov8865.
+
 config VIDEO_OV9640
tristate "OmniVision OV9640 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 15d4d6382582..505c2067e780 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -82,6 +82,7 @@ obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
 obj-$(CONFIG_VIDEO_OV772X) += ov772x.o
 obj-$(CONFIG_VIDEO_OV7740) += ov7740.o
 obj-$(CONFIG_VIDEO_OV8856) += ov8856.o
+obj-$(CONFIG_VIDEO_OV8865) += ov8865.o
 obj-$(CONFIG_VIDEO_OV9640) += ov9640.o
 obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
 obj-$(CONFIG_VIDEO_OV13858) += ov13858.o
diff --git a/drivers/media/i2c/ov8865.c b/drivers/media/i2c/ov8865.c
new file mode 100644
index ..fda5a55979aa
--- /dev/null
+++ b/drivers/media/i2c/ov8865.c
@@ -0,0 +1,2972 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright 2020 Kévin L'hôpital 
+ * Copyright 2020 Bootlin
+ * Author: Paul Kocialkowski 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Clock rate */
+
+#define OV8865_EXTCLK_RATE 2400
+
+/* Register definitions */
+
+/* System */
+
+#define OV8865_SW_STANDBY_REG  0x100
+#define OV8865_SW_STANDBY_STREAM_ONBIT(0)
+
+#define OV8865_SW_RESET_REG0x103
+#define OV8865_SW_RESET_RESET  BIT(0)
+
+#define OV8865_PLL_CTRL0_REG   0x300
+#define OV8865_PLL_CTRL0_PRE_DIV(v)((v) & GENMASK(2, 0))
+#define OV8865_PLL_CTRL1_REG   0x301
+#define OV8865_PLL_CTRL1_MUL_H(v)  (((v) & GENMASK(9, 8)) >> 8)
+#define OV8865_PLL_CTRL2_REG   0x302
+#define OV8865_PLL_CTRL2_MUL_L(v)  ((v) & GENMASK(7, 0))
+#define OV8865_PLL_CTRL3_REG   0x303
+#define OV8865_PLL_CTRL3_M_DIV(v)  (((v) - 1) & GENMASK(3, 0))
+#define OV8865_PLL_CTRL4_REG   0x304
+#define OV8865_PLL_CTRL4_MIPI_DIV(v)   ((v) & GENMASK(1, 0))
+#define OV8865_PLL_CTRL5_REG   0x305
+#define OV8865_PLL_CTRL5_SYS_PRE_DIV(v)((v) & GENMASK(1, 0))
+#define OV8865_PLL_CTRL6_REG   0x306
+#define OV8865_PLL_CTRL6_SYS_DIV(v)(((v) - 1) & BIT(0))
+
+#define OV8865_PLL_CTRL8_REG   0x308
+#define OV8865_PLL_CTRL9_REG   0x309
+#define OV8865_PLL_CTRLA_REG   0x30a
+#define OV8865_PLL_CTRLA_PRE_DIV_HALF(v)   (((v) - 1) & BIT(0))
+#define OV8865_PLL_CTRLB_REG   0x30b
+#define OV8865_PLL_CTRLB_PRE_DIV(v)((v) & GENMASK(2, 0))
+#define OV8865_PLL_CTRLC_REG   0x30c
+#define OV8865_PLL_CTRLC_MUL_H(v)  (((v) & GENMASK(9, 8)) >> 8)
+#define OV8865_PLL_CTRLD_REG   0x30d
+#define OV8865_PLL_CTRLD_MUL_L(v)  ((v) & GENMASK(7, 0))
+#define OV8865_PLL_CTRLE_REG   0x30e
+#define OV8865_PLL_CTRLE_SYS_DIV(v)((v) & GENMASK(2, 0))
+#define OV8865_PLL_C

[PATCH v4 01/15] docs: phy: Add a part about PHY mode and submode

[Paul Kocialkowski]

Besides giving pointers to the relevant functions for PHY mode and
submode configuration, this clarifies the need to set them before
powering on the PHY.

Signed-off-by: Paul Kocialkowski 
Reviewed-by: Maxime Ripard 
---
 Documentation/driver-api/phy/phy.rst | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/Documentation/driver-api/phy/phy.rst 
b/Documentation/driver-api/phy/phy.rst
index 8fc1ce0bb905..6cbc72707a49 100644
--- a/Documentation/driver-api/phy/phy.rst
+++ b/Documentation/driver-api/phy/phy.rst
@@ -195,3 +195,21 @@ DeviceTree Binding
 
 The documentation for PHY dt binding can be found @
 Documentation/devicetree/bindings/phy/phy-bindings.txt
+
+PHY Mode and Submode
+
+
+Once a reference to a PHY is obtained by a controller, the PHY can be 
configured
+to a PHY mode and submode. PHY modes are described in the `phy_mode` enum while
+submodes are specific to the selected PHY mode.
+
+Mode and submode configuration is done by calling::
+
+   int phy_set_mode_ext(struct phy *phy, enum phy_mode mode, int submode);
+
+If no submode is to be configured, users can call::
+
+   int phy_set_mode(struct phy *phy, enum phy_mode mode);
+
+The PHY mode and submode must not be configured after the PHY has already been
+powered on.
-- 
2.29.2

[PATCH v4 03/15] phy: allwinner: phy-sun6i-mipi-dphy: Support D-PHY Rx mode for MIPI CSI-2

[Paul Kocialkowski]

The Allwinner A31 D-PHY supports both Rx and Tx modes. While the latter
is already supported and used for MIPI DSI this adds support for the
former, to be used with MIPI CSI-2.

This implementation is inspired by Allwinner's V3s Linux SDK
implementation, which was used as a documentation base.

Signed-off-by: Paul Kocialkowski 
Acked-by: Maxime Ripard 
---
 drivers/phy/allwinner/phy-sun6i-mipi-dphy.c | 164 +++-
 1 file changed, 160 insertions(+), 4 deletions(-)

diff --git a/drivers/phy/allwinner/phy-sun6i-mipi-dphy.c 
b/drivers/phy/allwinner/phy-sun6i-mipi-dphy.c
index 1fa761ba6cbb..0389b6b670d6 100644
--- a/drivers/phy/allwinner/phy-sun6i-mipi-dphy.c
+++ b/drivers/phy/allwinner/phy-sun6i-mipi-dphy.c
@@ -24,6 +24,14 @@
 #define SUN6I_DPHY_TX_CTL_REG  0x04
 #define SUN6I_DPHY_TX_CTL_HS_TX_CLK_CONT   BIT(28)
 
+#define SUN6I_DPHY_RX_CTL_REG  0x08
+#define SUN6I_DPHY_RX_CTL_EN_DBC   BIT(31)
+#define SUN6I_DPHY_RX_CTL_RX_CLK_FORCE BIT(24)
+#define SUN6I_DPHY_RX_CTL_RX_D3_FORCE  BIT(23)
+#define SUN6I_DPHY_RX_CTL_RX_D2_FORCE  BIT(22)
+#define SUN6I_DPHY_RX_CTL_RX_D1_FORCE  BIT(21)
+#define SUN6I_DPHY_RX_CTL_RX_D0_FORCE  BIT(20)
+
 #define SUN6I_DPHY_TX_TIME0_REG0x10
 #define SUN6I_DPHY_TX_TIME0_HS_TRAIL(n)(((n) & 0xff) << 24)
 #define SUN6I_DPHY_TX_TIME0_HS_PREPARE(n)  (((n) & 0xff) << 16)
@@ -44,12 +52,29 @@
 #define SUN6I_DPHY_TX_TIME4_HS_TX_ANA1(n)  (((n) & 0xff) << 8)
 #define SUN6I_DPHY_TX_TIME4_HS_TX_ANA0(n)  ((n) & 0xff)
 
+#define SUN6I_DPHY_RX_TIME0_REG0x30
+#define SUN6I_DPHY_RX_TIME0_HS_RX_SYNC(n)  (((n) & 0xff) << 24)
+#define SUN6I_DPHY_RX_TIME0_HS_RX_CLK_MISS(n)  (((n) & 0xff) << 16)
+#define SUN6I_DPHY_RX_TIME0_LP_RX(n)   (((n) & 0xff) << 8)
+
+#define SUN6I_DPHY_RX_TIME1_REG0x34
+#define SUN6I_DPHY_RX_TIME1_RX_DLY(n)  (((n) & 0xfff) << 20)
+#define SUN6I_DPHY_RX_TIME1_LP_RX_ULPS_WP(n)   ((n) & 0xf)
+
+#define SUN6I_DPHY_RX_TIME2_REG0x38
+#define SUN6I_DPHY_RX_TIME2_HS_RX_ANA1(n)  (((n) & 0xff) << 8)
+#define SUN6I_DPHY_RX_TIME2_HS_RX_ANA0(n)  ((n) & 0xff)
+
+#define SUN6I_DPHY_RX_TIME3_REG0x40
+#define SUN6I_DPHY_RX_TIME3_LPRST_DLY(n)   (((n) & 0x) << 16)
+
 #define SUN6I_DPHY_ANA0_REG0x4c
 #define SUN6I_DPHY_ANA0_REG_PWSBIT(31)
 #define SUN6I_DPHY_ANA0_REG_DMPC   BIT(28)
 #define SUN6I_DPHY_ANA0_REG_DMPD(n)(((n) & 0xf) << 24)
 #define SUN6I_DPHY_ANA0_REG_SLV(n) (((n) & 7) << 12)
 #define SUN6I_DPHY_ANA0_REG_DEN(n) (((n) & 0xf) << 8)
+#define SUN6I_DPHY_ANA0_REG_SFB(n) (((n) & 3) << 2)
 
 #define SUN6I_DPHY_ANA1_REG0x50
 #define SUN6I_DPHY_ANA1_REG_VTTMODEBIT(31)
@@ -92,6 +117,8 @@ struct sun6i_dphy {
 
struct phy  *phy;
struct phy_configure_opts_mipi_dphy config;
+
+   int submode;
 };
 
 static int sun6i_dphy_init(struct phy *phy)
@@ -105,6 +132,18 @@ static int sun6i_dphy_init(struct phy *phy)
return 0;
 }
 
+static int sun6i_dphy_set_mode(struct phy *phy, enum phy_mode mode, int 
submode)
+{
+   struct sun6i_dphy *dphy = phy_get_drvdata(phy);
+
+   if (mode != PHY_MODE_MIPI_DPHY)
+   return -EINVAL;
+
+   dphy->submode = submode;
+
+   return 0;
+}
+
 static int sun6i_dphy_configure(struct phy *phy, union phy_configure_opts 
*opts)
 {
struct sun6i_dphy *dphy = phy_get_drvdata(phy);
@@ -119,9 +158,8 @@ static int sun6i_dphy_configure(struct phy *phy, union 
phy_configure_opts *opts)
return 0;
 }
 
-static int sun6i_dphy_power_on(struct phy *phy)
+static int sun6i_dphy_tx_power_on(struct sun6i_dphy *dphy)
 {
-   struct sun6i_dphy *dphy = phy_get_drvdata(phy);
u8 lanes_mask = GENMASK(dphy->config.lanes - 1, 0);
 
regmap_write(dphy->regs, SUN6I_DPHY_TX_CTL_REG,
@@ -211,12 +249,129 @@ static int sun6i_dphy_power_on(struct phy *phy)
return 0;
 }
 
+static int sun6i_dphy_rx_power_on(struct sun6i_dphy *dphy)
+{
+   /* Physical clock rate is actually half of symbol rate with DDR. */
+   unsigned long mipi_symbol_rate = dphy->config.hs_clk_rate;
+   unsigned long dphy_clk_rate;
+   unsigned int rx_dly;
+   unsigned int lprst_dly;
+   u32 value;
+
+   dphy_clk_rate = clk_get_rate(dphy->mod_clk);
+   if (!dphy_clk_rate)
+   return -EINVAL;
+
+   /* Hardcoded timing parameters from the Allwinner BSP. */
+   regmap_write(dphy->regs, SUN6I_DPHY_RX_TIME0_REG,
+SUN6I_DPHY_RX_TIME0_HS_RX_SYNC(255) |
+SUN6I_DPHY_RX_TIME0_HS_RX_CLK_MISS(255) |
+SUN6I_DPHY_RX_TIME0_LP_RX(255));
+
+   /*
+* Formula from the Allwinner BSP, with hardcoded coefficients
+* (probably internal divider/multiplier).
+*/
+   rx_d

[PATCH v4 15/15] MAINTAINERS: Add entry for the Allwinner A83T MIPI CSI-2 bridge

[Paul Kocialkowski]

Add myself as maintainer of the A83T MIPI CSI-2 bridge media driver.

Signed-off-by: Paul Kocialkowski 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index a1352171778b..3b48612657b6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -717,6 +717,14 @@ T: git git://linuxtv.org/media_tree.git
 F: 
Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml
 F: drivers/media/platform/sunxi/sun6i-mipi-csi2/
 
+ALLWINNER A83T MIPI CSI-2 BRIDGE
+M: Paul Kocialkowski 
+L: linux-me...@vger.kernel.org
+S: Maintained
+T: git git://linuxtv.org/media_tree.git
+F: 
Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml
+F: drivers/media/platform/sunxi/sun8i-a83t-mipi-csi2/
+
 ALLWINNER CPUFREQ DRIVER
 M: Yangtao Li 
 L: linux...@vger.kernel.org
-- 
2.29.2

[PATCH v4 05/15] media: sun6i-csi: Only configure the interface data width for parallel

[Paul Kocialkowski]

Bits related to the interface data width are only applicable to the
parallel interface and are irrelevant when the CSI controller is taking
input from the MIPI CSI-2 controller.

In prevision of adding support for this case, set these bits
conditionally so there is no ambiguity. The conditional block is
moved around before the interlaced conditional block for nicer code
symmetry (conditional blocks first) while at it.

Co-developed-by: Kévin L'hôpital 
Signed-off-by: Kévin L'hôpital 
Signed-off-by: Paul Kocialkowski 
---
 .../platform/sunxi/sun6i-csi/sun6i_csi.c  | 42 +++
 1 file changed, 25 insertions(+), 17 deletions(-)

diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c 
b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
index 531a4cccd14a..f1150de94e98 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
@@ -378,8 +378,13 @@ static void sun6i_csi_setup_bus(struct sun6i_csi_dev *sdev)
unsigned char bus_width;
u32 flags;
u32 cfg;
+   bool input_parallel = false;
bool input_interlaced = false;
 
+   if (endpoint->bus_type == V4L2_MBUS_PARALLEL ||
+   endpoint->bus_type == V4L2_MBUS_BT656)
+   input_parallel = true;
+
if (csi->config.field == V4L2_FIELD_INTERLACED
|| csi->config.field == V4L2_FIELD_INTERLACED_TB
|| csi->config.field == V4L2_FIELD_INTERLACED_BT)
@@ -395,6 +400,26 @@ static void sun6i_csi_setup_bus(struct sun6i_csi_dev *sdev)
 CSI_IF_CFG_HREF_POL_MASK | CSI_IF_CFG_FIELD_MASK |
 CSI_IF_CFG_SRC_TYPE_MASK);
 
+   if (input_parallel) {
+   switch (bus_width) {
+   case 8:
+   cfg |= CSI_IF_CFG_IF_DATA_WIDTH_8BIT;
+   break;
+   case 10:
+   cfg |= CSI_IF_CFG_IF_DATA_WIDTH_10BIT;
+   break;
+   case 12:
+   cfg |= CSI_IF_CFG_IF_DATA_WIDTH_12BIT;
+   break;
+   case 16: /* No need to configure DATA_WIDTH for 16bit */
+   break;
+   default:
+   dev_warn(sdev->dev, "Unsupported bus width: %u\n",
+bus_width);
+   break;
+   }
+   }
+
if (input_interlaced)
cfg |= CSI_IF_CFG_SRC_TYPE_INTERLACED;
else
@@ -440,23 +465,6 @@ static void sun6i_csi_setup_bus(struct sun6i_csi_dev *sdev)
break;
}
 
-   switch (bus_width) {
-   case 8:
-   cfg |= CSI_IF_CFG_IF_DATA_WIDTH_8BIT;
-   break;
-   case 10:
-   cfg |= CSI_IF_CFG_IF_DATA_WIDTH_10BIT;
-   break;
-   case 12:
-   cfg |= CSI_IF_CFG_IF_DATA_WIDTH_12BIT;
-   break;
-   case 16: /* No need to configure DATA_WIDTH for 16bit */
-   break;
-   default:
-   dev_warn(sdev->dev, "Unsupported bus width: %u\n", bus_width);
-   break;
-   }
-
regmap_write(sdev->regmap, CSI_IF_CFG_REG, cfg);
 }
 
-- 
2.29.2

[PATCH v4 06/15] dt-bindings: media: sun6i-a31-csi: Add MIPI CSI-2 input port

[Paul Kocialkowski]

The A31 CSI controller supports two distinct input interfaces:
parallel and an external MIPI CSI-2 bridge. The parallel interface
is often connected to a set of hardware pins while the MIPI CSI-2
bridge is an internal FIFO-ish link. As a result, these two inputs
are distinguished as two different ports.

Note that only one of the two may be present on a controller instance.
For example, the V3s has one controller dedicated to MIPI-CSI2 and one
dedicated to parallel.

Update the binding with an explicit ports node that holds two distinct
port nodes: one for parallel input and one for MIPI CSI-2.

This is backward-compatible with the single-port approach that was
previously taken for representing the parallel interface port, which
stays enumerated as fwnode port 0.

Note that additional ports may be added in the future, especially to
support feeding the CSI controller's output to the ISP.

Signed-off-by: Paul Kocialkowski 
Reviewed-by: Rob Herring 
---
 .../media/allwinner,sun6i-a31-csi.yaml| 88 ---
 1 file changed, 75 insertions(+), 13 deletions(-)

diff --git 
a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml 
b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
index 1fd9b5532a21..77ded77505e9 100644
--- a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
+++ b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml
@@ -67,6 +67,62 @@ properties:
 
 additionalProperties: false
 
+  ports:
+type: object
+
+properties:
+  port@0:
+type: object
+description: Parallel input port, connect to a parallel sensor
+
+properties:
+  reg:
+const: 0
+
+  endpoint:
+type: object
+
+properties:
+  remote-endpoint: true
+
+  bus-width:
+enum: [ 8, 10, 12, 16 ]
+
+  pclk-sample: true
+  hsync-active: true
+  vsync-active: true
+
+required:
+  - bus-width
+  - remote-endpoint
+
+required:
+  - endpoint
+
+additionalProperties: false
+
+  port@1:
+type: object
+description: MIPI CSI-2 bridge input port
+
+properties:
+  reg:
+const: 1
+
+  endpoint:
+type: object
+
+properties:
+  remote-endpoint: true
+
+required:
+  - remote-endpoint
+
+required:
+  - endpoint
+
+additionalProperties: false
+
 required:
   - compatible
   - reg
@@ -95,19 +151,25 @@ examples:
   "ram";
 resets = <&ccu RST_BUS_CSI>;
 
-port {
-/* Parallel bus endpoint */
-csi1_ep: endpoint {
-remote-endpoint = <&adv7611_ep>;
-bus-width = <16>;
-
-/*
- * If hsync-active/vsync-active are missing,
- * embedded BT.656 sync is used.
- */
- hsync-active = <0>; /* Active low */
- vsync-active = <0>; /* Active low */
- pclk-sample = <1>;  /* Rising */
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+port@0 {
+reg = <0>;
+/* Parallel bus endpoint */
+csi1_ep: endpoint {
+remote-endpoint = <&adv7611_ep>;
+bus-width = <16>;
+
+/*
+ * If hsync-active/vsync-active are missing,
+ * embedded BT.656 sync is used.
+ */
+ hsync-active = <0>; /* Active low */
+ vsync-active = <0>; /* Active low */
+ pclk-sample = <1>;  /* Rising */
+};
 };
 };
 };
-- 
2.29.2

[PATCH v4 07/15] media: sun6i-csi: Add support for MIPI CSI-2 bridge input

[Paul Kocialkowski]

The A31 CSI controller supports a MIPI CSI-2 bridge input, which has
its own dedicated port in the fwnode graph.

Support for this input is added with this change:
- two pads are defined for the media entity instead of one
  and only one needs to be connected at a time;
- the pads currently match the fwnode graph representation;
- links are created between our pads and the subdevs for each
  interface and are no longer immutable so that userspace can select
  which interface to use in case both are bound to a subdev;
- fwnode endpoints are parsed and stored for each interface;
- the active subdev (and fwnode endpoint) is retrieved when validating
  the media link at stream on time and cleared at stream off;
- an error is raised if both links are active at the same time;
- the MIPI interface bit is set if the MIPI CSI-2 bridge endpoint is
  active.

In the future, the media entity representation might evolve to:
- distinguish the internal parallel bridge and data formatter;
- represent each of the 4 internal channels that can exist between
  the parallel bridge (for BT656 time-multiplex) and MIPI CSI-2
  (internal channels can be mapped to virtual channels);
- connect the controller's output to the ISP instead of its
  DMA engine.

Finally note that the MIPI CSI-2 bridges should not be linked in
the fwnode graph unless they have a sensor subdev attached.

Signed-off-by: Paul Kocialkowski 
---
 .../platform/sunxi/sun6i-csi/sun6i_csi.c  | 123 ++
 .../platform/sunxi/sun6i-csi/sun6i_csi.h  |   9 +-
 .../platform/sunxi/sun6i-csi/sun6i_video.c|  57 
 .../platform/sunxi/sun6i-csi/sun6i_video.h|   7 +-
 4 files changed, 142 insertions(+), 54 deletions(-)

diff --git a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c 
b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
index f1150de94e98..dcf465d73579 100644
--- a/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
+++ b/drivers/media/platform/sunxi/sun6i-csi/sun6i_csi.c
@@ -49,6 +49,7 @@ static inline struct sun6i_csi_dev *sun6i_csi_to_dev(struct 
sun6i_csi *csi)
 
 /* TODO add 10&12 bit YUV, RGB support */
 bool sun6i_csi_is_format_supported(struct sun6i_csi *csi,
+  struct v4l2_fwnode_endpoint *endpoint,
   u32 pixformat, u32 mbus_code)
 {
struct sun6i_csi_dev *sdev = sun6i_csi_to_dev(csi);
@@ -58,9 +59,9 @@ bool sun6i_csi_is_format_supported(struct sun6i_csi *csi,
 * 8bit and 16bit bus width.
 * Identify the media bus format from device tree.
 */
-   if ((sdev->csi.v4l2_ep.bus_type == V4L2_MBUS_PARALLEL
-|| sdev->csi.v4l2_ep.bus_type == V4L2_MBUS_BT656)
-&& sdev->csi.v4l2_ep.bus.parallel.bus_width == 16) {
+   if ((endpoint->bus_type == V4L2_MBUS_PARALLEL ||
+endpoint->bus_type == V4L2_MBUS_BT656) &&
+   endpoint->bus.parallel.bus_width == 16) {
switch (pixformat) {
case V4L2_PIX_FMT_HM12:
case V4L2_PIX_FMT_NV12:
@@ -373,7 +374,7 @@ static enum csi_input_seq get_csi_input_seq(struct 
sun6i_csi_dev *sdev,
 
 static void sun6i_csi_setup_bus(struct sun6i_csi_dev *sdev)
 {
-   struct v4l2_fwnode_endpoint *endpoint = &sdev->csi.v4l2_ep;
+   struct v4l2_fwnode_endpoint *endpoint = sdev->csi.video.source_endpoint;
struct sun6i_csi *csi = &sdev->csi;
unsigned char bus_width;
u32 flags;
@@ -459,6 +460,9 @@ static void sun6i_csi_setup_bus(struct sun6i_csi_dev *sdev)
if (flags & V4L2_MBUS_PCLK_SAMPLE_FALLING)
cfg |= CSI_IF_CFG_CLK_POL_FALLING_EDGE;
break;
+   case V4L2_MBUS_CSI2_DPHY:
+   cfg |= CSI_IF_CFG_MIPI_IF_MIPI;
+   break;
default:
dev_warn(sdev->dev, "Unsupported bus type: %d\n",
 endpoint->bus_type);
@@ -636,11 +640,11 @@ void sun6i_csi_set_stream(struct sun6i_csi *csi, bool 
enable)
  * Media Controller and V4L2
  */
 static int sun6i_csi_link_entity(struct sun6i_csi *csi,
+struct media_pad *sink_pad,
 struct media_entity *entity,
-struct fwnode_handle *fwnode)
+struct fwnode_handle *fwnode, bool enabled)
 {
struct media_entity *sink;
-   struct media_pad *sink_pad;
int src_pad_index;
int ret;
 
@@ -654,14 +658,12 @@ static int sun6i_csi_link_entity(struct sun6i_csi *csi,
src_pad_index = ret;
 
sink = &csi->video.vdev.entity;
-   sink_pad = &csi->video.pad;
 
dev_dbg(csi->dev, "creating %s:%u -> %s:%u link\n",
entity->name, src_pad_index, sink->name, sink_pad->index);
ret = media_create_pad_link(entity, src_pad_index, sink,
sink_pad->index,
-   MEDIA_LNK_FL_ENABLED |
- 

[PATCH v4 08/15] dt-bindings: media: Add A31 MIPI CSI-2 bindings documentation

[Paul Kocialkowski]

This introduces YAML bindings documentation for the A31 MIPI CSI-2
controller.

Signed-off-by: Paul Kocialkowski 
---
 .../media/allwinner,sun6i-a31-mipi-csi2.yaml  | 149 ++
 1 file changed, 149 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml

diff --git 
a/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml 
b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml
new file mode 100644
index ..bb05105c45b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/allwinner,sun6i-a31-mipi-csi2.yaml
@@ -0,0 +1,149 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/allwinner,sun6i-a31-mipi-csi2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner A31 MIPI CSI-2 Device Tree Bindings
+
+maintainers:
+  - Paul Kocialkowski 
+
+properties:
+  compatible:
+oneOf:
+  - const: allwinner,sun6i-a31-mipi-csi2
+  - items:
+  - const: allwinner,sun8i-v3s-mipi-csi2
+  - const: allwinner,sun6i-a31-mipi-csi2
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+items:
+  - description: Bus Clock
+  - description: Module Clock
+
+  clock-names:
+items:
+  - const: bus
+  - const: mod
+
+  phys:
+maxItems: 1
+description: MIPI D-PHY
+
+  resets:
+maxItems: 1
+
+  # See ./video-interfaces.txt for details
+  ports:
+type: object
+
+properties:
+  port@0:
+type: object
+description: Input port, connect to a MIPI CSI-2 sensor
+
+properties:
+  reg:
+const: 0
+
+  endpoint:
+type: object
+
+properties:
+  remote-endpoint: true
+
+  data-lanes:
+minItems: 1
+maxItems: 4
+
+required:
+  - data-lanes
+  - remote-endpoint
+
+required:
+  - endpoint
+
+additionalProperties: false
+
+  port@1:
+type: object
+description: Output port, connect to a CSI controller
+
+properties:
+  reg:
+const: 1
+
+  endpoint:
+type: object
+
+properties:
+  remote-endpoint: true
+
+required:
+  - remote-endpoint
+
+required:
+  - endpoint
+
+additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+  - resets
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+#include 
+
+mipi_csi2: csi@1cb1000 {
+compatible = "allwinner,sun8i-v3s-mipi-csi2",
+ "allwinner,sun6i-a31-mipi-csi2";
+reg = <0x01cb1000 0x1000>;
+interrupts = ;
+clocks = <&ccu CLK_BUS_CSI>,
+ <&ccu CLK_CSI1_SCLK>;
+clock-names = "bus", "mod";
+resets = <&ccu RST_BUS_CSI>;
+
+phys = <&dphy>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+mipi_csi2_in: port@0 {
+reg = <0>;
+
+mipi_csi2_in_ov5648: endpoint {
+data-lanes = <1 2 3 4>;
+
+remote-endpoint = <&ov5648_out_mipi_csi2>;
+};
+};
+
+mipi_csi2_out: port@1 {
+reg = <1>;
+
+mipi_csi2_out_csi0: endpoint {
+remote-endpoint = <&csi0_in_mipi_csi2>;
+};
+};
+};
+};
+
+...
-- 
2.29.2

[PATCH v4 09/15] media: sunxi: Add support for the A31 MIPI CSI-2 controller

[Paul Kocialkowski]

The A31 MIPI CSI-2 controller is a dedicated MIPI CSI-2 bridge
found on Allwinner SoCs such as the A31 and V3/V3s.

It is a standalone block, connected to the CSI controller on one side
and to the MIPI D-PHY block on the other. It has a dedicated address
space, interrupt line and clock.

It is represented as a V4L2 subdev to the CSI controller and takes a
MIPI CSI-2 sensor as its own subdev, all using the fwnode graph and
media controller API.

Only 8-bit and 10-bit Bayer formats are currently supported.
While up to 4 internal channels to the CSI controller exist, only one
is currently supported by this implementation.

Signed-off-by: Paul Kocialkowski 
---
 drivers/media/platform/sunxi/Kconfig  |   1 +
 drivers/media/platform/sunxi/Makefile |   1 +
 .../platform/sunxi/sun6i-mipi-csi2/Kconfig|  12 +
 .../platform/sunxi/sun6i-mipi-csi2/Makefile   |   4 +
 .../sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c   | 590 ++
 .../sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.h   | 117 
 6 files changed, 725 insertions(+)
 create mode 100644 drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
 create mode 100644 drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
 create mode 100644 
drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
 create mode 100644 
drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.h

diff --git a/drivers/media/platform/sunxi/Kconfig 
b/drivers/media/platform/sunxi/Kconfig
index 7151cc249afa..9684e07454ad 100644
--- a/drivers/media/platform/sunxi/Kconfig
+++ b/drivers/media/platform/sunxi/Kconfig
@@ -2,3 +2,4 @@
 
 source "drivers/media/platform/sunxi/sun4i-csi/Kconfig"
 source "drivers/media/platform/sunxi/sun6i-csi/Kconfig"
+source "drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig"
diff --git a/drivers/media/platform/sunxi/Makefile 
b/drivers/media/platform/sunxi/Makefile
index fc537c9f5ca9..887a7cae8fca 100644
--- a/drivers/media/platform/sunxi/Makefile
+++ b/drivers/media/platform/sunxi/Makefile
@@ -2,5 +2,6 @@
 
 obj-y  += sun4i-csi/
 obj-y  += sun6i-csi/
+obj-y  += sun6i-mipi-csi2/
 obj-y  += sun8i-di/
 obj-y  += sun8i-rotate/
diff --git a/drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig 
b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
new file mode 100644
index ..47f1bb0779a8
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Kconfig
@@ -0,0 +1,12 @@
+# SPDX-License-Identifier: GPL-2.0-only
+config VIDEO_SUN6I_MIPI_CSI2
+   tristate "Allwinner A31 MIPI CSI-2 Controller Driver"
+   depends on ARCH_SUNXI || COMPILE_TEST
+   depends on PM && COMMON_CLK && VIDEO_V4L2
+   select REGMAP_MMIO
+   select PHY_SUN6I_MIPI_DPHY
+   select MEDIA_CONTROLLER
+   select VIDEO_V4L2_SUBDEV_API
+   select V4L2_FWNODE
+   help
+  Support for the Allwinner A31 MIPI CSI-2 Controller.
diff --git a/drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile 
b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
new file mode 100644
index ..14e4e03818b5
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun6i-mipi-csi2/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0-only
+sun6i-mipi-csi2-y += sun6i_mipi_csi2.o
+
+obj-$(CONFIG_VIDEO_SUN6I_MIPI_CSI2) += sun6i-mipi-csi2.o
diff --git a/drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c 
b/drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
new file mode 100644
index ..87307beda4cf
--- /dev/null
+++ b/drivers/media/platform/sunxi/sun6i-mipi-csi2/sun6i_mipi_csi2.c
@@ -0,0 +1,590 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2020 Bootlin
+ * Author: Paul Kocialkowski 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sun6i_mipi_csi2.h"
+
+#define MODULE_NAME"sun6i-mipi-csi2"
+
+static const u32 sun6i_mipi_csi2_mbus_codes[] = {
+   MEDIA_BUS_FMT_SBGGR8_1X8,
+   MEDIA_BUS_FMT_SGBRG8_1X8,
+   MEDIA_BUS_FMT_SGRBG8_1X8,
+   MEDIA_BUS_FMT_SRGGB8_1X8,
+   MEDIA_BUS_FMT_SBGGR10_1X10,
+   MEDIA_BUS_FMT_SGBRG10_1X10,
+   MEDIA_BUS_FMT_SGRBG10_1X10,
+   MEDIA_BUS_FMT_SRGGB10_1X10,
+};
+
+/* Video */
+
+static int sun6i_mipi_csi2_s_stream(struct v4l2_subdev *subdev, int on)
+{
+   struct sun6i_mipi_csi2_video *video =
+   sun6i_mipi_csi2_subdev_video(subdev);
+   struct sun6i_mipi_csi2_dev *cdev = sun6i_mipi_csi2_video_dev(video);
+   struct v4l2_subdev *remote_subdev = video->remote_subdev;
+   struct v4l2_fwnode_bus_mipi_csi2 *bus_mipi_csi2 =
+   &video->endpoint.bus.mipi_csi2;
+   union phy_configure_opts dphy_opts = { 0 };
+   struct phy_configure_opts_mipi_dphy *dphy_cfg = &dphy_opts.mipi_dphy;
+   struct regmap *regmap = cdev->regmap;
+   struct v4l2_ctrl *ctrl;
+   unsigned int lanes_count;
+   unsigned int bpp;
+   unsigne

[PATCH v4 02/15] phy: Distinguish between Rx and Tx for MIPI D-PHY with submodes

[Paul Kocialkowski]

As some D-PHY controllers support both Rx and Tx mode, we need a way for
users to explicitly request one or the other. For instance, Rx mode can
be used along with MIPI CSI-2 while Tx mode can be used with MIPI DSI.

Introduce new MIPI D-PHY PHY submodes to use with PHY_MODE_MIPI_DPHY.
The default (zero value) is kept to Tx so only the rkisp1 driver, which
uses D-PHY in Rx mode, needs to be adapted.

Signed-off-by: Paul Kocialkowski 
Acked-by: Helen Koike 
---
 drivers/staging/media/rkisp1/rkisp1-isp.c |  3 ++-
 include/linux/phy/phy-mipi-dphy.h | 13 +
 2 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/rkisp1/rkisp1-isp.c 
b/drivers/staging/media/rkisp1/rkisp1-isp.c
index a9715b0b7264..f1167995688a 100644
--- a/drivers/staging/media/rkisp1/rkisp1-isp.c
+++ b/drivers/staging/media/rkisp1/rkisp1-isp.c
@@ -914,7 +914,8 @@ static int rkisp1_mipi_csi2_start(struct rkisp1_isp *isp,
 
phy_mipi_dphy_get_default_config(pixel_clock, isp->sink_fmt->bus_width,
 sensor->lanes, cfg);
-   phy_set_mode(sensor->dphy, PHY_MODE_MIPI_DPHY);
+   phy_set_mode_ext(cdev->dphy, PHY_MODE_MIPI_DPHY,
+PHY_MIPI_DPHY_SUBMODE_RX);
phy_configure(sensor->dphy, &opts);
phy_power_on(sensor->dphy);
 
diff --git a/include/linux/phy/phy-mipi-dphy.h 
b/include/linux/phy/phy-mipi-dphy.h
index a877ffee845d..0f57ef46a8b5 100644
--- a/include/linux/phy/phy-mipi-dphy.h
+++ b/include/linux/phy/phy-mipi-dphy.h
@@ -6,6 +6,19 @@
 #ifndef __PHY_MIPI_DPHY_H_
 #define __PHY_MIPI_DPHY_H_
 
+/**
+ * enum phy_mipi_dphy_submode - MIPI D-PHY sub-mode
+ *
+ * A MIPI D-PHY can be used to transmit or receive data.
+ * Since some controllers can support both, the direction to enable is 
specified
+ * with the PHY sub-mode. Transmit is assumed by default with phy_set_mode.
+ */
+
+enum phy_mipi_dphy_submode {
+   PHY_MIPI_DPHY_SUBMODE_TX = 0,
+   PHY_MIPI_DPHY_SUBMODE_RX,
+};
+
 /**
  * struct phy_configure_opts_mipi_dphy - MIPI D-PHY configuration set
  *
-- 
2.29.2

[PATCH v4 10/15] ARM: dts: sun8i: v3s: Add nodes for MIPI CSI-2 support

[Paul Kocialkowski]

MIPI CSI-2 is supported on the V3s with an A31-based MIPI CSI-2 bridge
controller. The controller uses a separate D-PHY, which is the same
that is otherwise used for MIPI DSI, but used in Rx mode.

On the V3s, the CSI0 controller is dedicated to MIPI CSI-2 as it does
not have access to any parallel interface pins.

Add all the necessary nodes (CSI0, MIPI CSI-2 bridge and D-PHY) to
support the MIPI CSI-2 interface.

Note that a fwnode graph link is created between CSI0 and MIPI CSI-2
even when no sensor is connected. This will result in a probe failure
for the controller as long as no sensor is connected but this is fine
since no other interface is available.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/boot/dts/sun8i-v3s.dtsi | 67 
 1 file changed, 67 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 7b2d684aeb97..b7f2bcd25c86 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -530,6 +530,31 @@ spi0: spi@1c68000 {
#size-cells = <0>;
};
 
+   csi0: camera@1cb {
+   compatible = "allwinner,sun8i-v3s-csi";
+   reg = <0x01cb 0x1000>;
+   interrupts = ;
+   clocks = <&ccu CLK_BUS_CSI>,
+<&ccu CLK_CSI1_SCLK>,
+<&ccu CLK_DRAM_CSI>;
+   clock-names = "bus", "mod", "ram";
+   resets = <&ccu RST_BUS_CSI>;
+   status = "disabled";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   reg = <1>;
+
+   csi0_in_mipi_csi2: endpoint {
+   remote-endpoint = 
<&mipi_csi2_out_csi0>;
+   };
+   };
+   };
+   };
+
csi1: camera@1cb4000 {
compatible = "allwinner,sun8i-v3s-csi";
reg = <0x01cb4000 0x3000>;
@@ -552,5 +577,47 @@ gic: interrupt-controller@1c81000 {
#interrupt-cells = <3>;
interrupts = ;
};
+
+   mipi_csi2: csi@1cb1000 {
+   compatible = "allwinner,sun8i-v3s-mipi-csi2",
+"allwinner,sun6i-a31-mipi-csi2";
+   reg = <0x01cb1000 0x1000>;
+   interrupts = ;
+   clocks = <&ccu CLK_BUS_CSI>,
+<&ccu CLK_CSI1_SCLK>;
+   clock-names = "bus", "mod";
+   resets = <&ccu RST_BUS_CSI>;
+   status = "disabled";
+
+   phys = <&dphy>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   mipi_csi2_in: port@0 {
+   reg = <0>;
+   };
+
+   mipi_csi2_out: port@1 {
+   reg = <1>;
+
+   mipi_csi2_out_csi0: endpoint {
+   remote-endpoint = 
<&csi0_in_mipi_csi2>;
+   };
+   };
+   };
+   };
+
+   dphy: d-phy@1cb2000 {
+   compatible = "allwinner,sun6i-a31-mipi-dphy";
+   reg = <0x01cb2000 0x1000>;
+   clocks = <&ccu CLK_BUS_CSI>,
+<&ccu CLK_MIPI_CSI>;
+   clock-names = "bus", "mod";
+   resets = <&ccu RST_BUS_CSI>;
+   status = "disabled";
+   #phy-cells = <0>;
+   };
};
 };
-- 
2.29.2

[PATCH v4 12/15] dt-bindings: media: Add A83T MIPI CSI-2 bindings documentation

[Paul Kocialkowski]

This introduces YAML bindings documentation for the A83T MIPI CSI-2
controller.

Signed-off-by: Paul Kocialkowski 
Reviewed-by: Rob Herring 
---
 .../media/allwinner,sun8i-a83t-mipi-csi2.yaml | 147 ++
 1 file changed, 147 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml

diff --git 
a/Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml 
b/Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml
new file mode 100644
index ..e607fae7d85e
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-mipi-csi2.yaml
@@ -0,0 +1,147 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/allwinner,sun8i-a83t-mipi-csi2.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Allwinner A83T MIPI CSI-2 Device Tree Bindings
+
+maintainers:
+  - Paul Kocialkowski 
+
+properties:
+  compatible:
+const: allwinner,sun8i-a83t-mipi-csi2
+
+  reg:
+maxItems: 1
+
+  interrupts:
+maxItems: 1
+
+  clocks:
+items:
+  - description: Bus Clock
+  - description: Module Clock
+  - description: MIPI-specific Clock
+  - description: Misc CSI Clock
+
+  clock-names:
+items:
+  - const: bus
+  - const: mod
+  - const: mipi
+  - const: misc
+
+  resets:
+maxItems: 1
+
+  # See ./video-interfaces.txt for details
+  ports:
+type: object
+
+properties:
+  port@0:
+type: object
+description: Input port, connect to a MIPI CSI-2 sensor
+
+properties:
+  reg:
+const: 0
+
+  endpoint:
+type: object
+
+properties:
+  remote-endpoint: true
+
+  clock-lanes:
+maxItems: 1
+
+  data-lanes:
+minItems: 1
+maxItems: 4
+
+required:
+  - data-lanes
+  - remote-endpoint
+
+required:
+  - endpoint
+
+additionalProperties: false
+
+  port@1:
+type: object
+description: Output port, connect to a CSI controller
+
+properties:
+  reg:
+const: 1
+
+  endpoint:
+type: object
+
+properties:
+  remote-endpoint: true
+
+required:
+  - remote-endpoint
+
+required:
+  - endpoint
+
+additionalProperties: false
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - clocks
+  - clock-names
+  - resets
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+#include 
+#include 
+
+mipi_csi2: csi@1cb1000 {
+compatible = "allwinner,sun8i-a83t-mipi-csi2";
+reg = <0x01cb1000 0x1000>;
+interrupts = ;
+clocks = <&ccu CLK_BUS_CSI>,
+ <&ccu CLK_CSI_SCLK>,
+ <&ccu CLK_MIPI_CSI>,
+ <&ccu CLK_CSI_MISC>;
+clock-names = "bus", "mod", "mipi", "misc";
+resets = <&ccu RST_BUS_CSI>;
+
+ports {
+#address-cells = <1>;
+#size-cells = <0>;
+
+mipi_csi2_in: port@0 {
+reg = <0>;
+
+mipi_csi2_in_ov8865: endpoint {
+data-lanes = <1 2 3 4>;
+
+remote-endpoint = <&ov8865_out_mipi_csi2>;
+};
+};
+
+mipi_csi2_out: port@1 {
+reg = <1>;
+
+mipi_csi2_out_csi: endpoint {
+remote-endpoint = <&csi_in_mipi_csi2>;
+};
+};
+};
+};
+
+...
-- 
2.29.2