Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [V9, 1/2] media: dt-bindings: media: i2c: Document OV02A10 bindings
From: Dongchun Zhu @ 2020-05-23  8:41 UTC (permalink / raw)
  To: linus.walleij, bgolaszewski, mchehab, andriy.shevchenko, robh+dt,
	mark.rutland, sakari.ailus, drinkcat, tfiga, matthias.bgg,
	bingbu.cao
  Cc: devicetree, srv_heupstream, shengnan.wang, sj.huang,
	linux-mediatek, dongchun.zhu, louis.kuo, linux-arm-kernel,
	linux-media
In-Reply-To: <20200523084103.31276-1-dongchun.zhu@mediatek.com>

Add DT bindings documentation for Omnivision OV02A10 image sensor.

Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
---
 .../bindings/media/i2c/ovti,ov02a10.yaml           | 172 +++++++++++++++++++++
 MAINTAINERS                                        |   7 +
 2 files changed, 179 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml

diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
new file mode 100644
index 0000000..56f31b5
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
@@ -0,0 +1,172 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# Copyright (c) 2020 MediaTek Inc.
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/i2c/ovti,ov02a10.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Omnivision OV02A10 CMOS Sensor Device Tree Bindings
+
+maintainers:
+  - Dongchun Zhu <dongchun.zhu@mediatek.com>
+
+description: |-
+  The Omnivision OV02A10 is a low-cost, high performance, 1/5-inch, 2 megapixel
+  image sensor, which is the latest production derived from Omnivision's CMOS
+  image sensor technology. Ihis chip supports high frame rate speeds up to 30fps
+  @ 1600x1200 (UXGA) resolution transferred over a 1-lane MIPI interface. The
+  sensor output is available via CSI-2 serial data output.
+
+properties:
+  compatible:
+    const: ovti,ov02a10
+
+  reg:
+    maxItems: 1
+
+  clocks:
+    items:
+      - description: top mux camtg clock
+      - description: divider clock
+
+  clock-names:
+    items:
+      - const: eclk
+      - const: freq_mux
+
+  clock-frequency:
+    description:
+      Frequency of the eclk clock in Hertz.
+
+  dovdd-supply:
+    description:
+      Definition of the regulator used as Digital I/O voltage supply.
+
+  avdd-supply:
+    description:
+      Definition of the regulator used as Analog voltage supply.
+
+  dvdd-supply:
+    description:
+      Definition of the regulator used as Digital core voltage supply.
+
+  powerdown-gpios:
+    description:
+      Must be the device tree identifier of the GPIO connected to the
+      PD_PAD pin. This pin is used to place the OV02A10 into Standby mode
+      or Shutdown mode. As the line is active low, it should be
+      marked GPIO_ACTIVE_LOW.
+
+  reset-gpios:
+    description:
+      Must be the device tree identifier of the GPIO connected to the
+      RST_PD pin. If specified, it will be asserted during driver probe.
+      As the line is active high, it should be marked GPIO_ACTIVE_HIGH.
+
+  rotation:
+    description:
+      Definition of the sensor's placement.
+    allOf:
+      - $ref: "/schemas/types.yaml#/definitions/uint32"
+      - enum:
+          - 0    # Sensor Mounted Upright
+          - 180  # Sensor Mounted Upside Down
+        default: 0
+
+  ovti,mipi-tx-speed:
+    description:
+      Indication of MIPI transmission speed select, which is to control D-PHY
+      timing setting by adjusting MIPI clock voltage to improve the clock
+      driver capability.
+    allOf:
+      - $ref: "/schemas/types.yaml#/definitions/uint32"
+      - enum:
+          - 0    #  20MHz -  30MHz
+          - 1    #  30MHz -  50MHz
+          - 2    #  50MHz -  75MHz
+          - 3    #  75MHz - 100MHz
+          - 4    # 100MHz - 130MHz
+        default: 3
+
+  # See ../video-interfaces.txt for details
+  port:
+    type: object
+    additionalProperties: false
+
+    properties:
+      endpoint:
+        type: object
+        additionalProperties: false
+
+        properties:
+          data-lanes:
+            maxItems: 1
+
+          link-frequencies: true
+          remote-endpoint: true
+
+        required:
+          - data-lanes
+          - link-frequencies
+          - remote-endpoint
+
+    required:
+      - endpoint
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - clock-names
+  - clock-frequency
+  - dovdd-supply
+  - avdd-supply
+  - dvdd-supply
+  - powerdown-gpios
+  - reset-gpios
+  - port
+
+additionalProperties: false
+
+examples:
+  - |
+
+    #include <dt-bindings/clock/mt8183-clk.h>
+    #include <dt-bindings/gpio/gpio.h>
+
+    i2c {
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        ov02a10: camera-sensor@3d {
+            compatible = "ovti,ov02a10";
+            reg = <0x3d>;
+            pinctrl-names = "default";
+            pinctrl-0 = <&clk_24m_cam>;
+
+            clocks = <&topckgen CLK_TOP_MUX_CAMTG>,
+                     <&topckgen CLK_TOP_UNIVP_192M_D8>;
+            clock-names = "eclk", "freq_mux";
+            clock-frequency = <24000000>;
+
+            rotation = <180>;
+            ovti,mipi-tx-speed = <4>;
+
+            dovdd-supply = <&mt6358_vcamio_reg>;
+            avdd-supply = <&mt6358_vcama1_reg>;
+            dvdd-supply = <&mt6358_vcn18_reg>;
+
+            powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
+            reset-gpios = <&pio 109 GPIO_ACTIVE_HIGH>;
+
+            port {
+                wcam_out: endpoint {
+                    data-lanes = <1>;
+                    link-frequencies = /bits/ 64 <390000000>;
+                    remote-endpoint = <&mipi_in_wcam>;
+                };
+            };
+        };
+    };
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index e64e5db..63a2335 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12389,6 +12389,13 @@ M:	Harald Welte <laforge@gnumonks.org>
 S:	Maintained
 F:	drivers/char/pcmcia/cm4040_cs.*
 
+OMNIVISION OV02A10 SENSOR DRIVER
+M:	Dongchun Zhu <dongchun.zhu@mediatek.com>
+L:	linux-media@vger.kernel.org
+S:	Maintained
+T:	git git://linuxtv.org/media_tree.git
+F:	Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
+
 OMNIVISION OV13858 SENSOR DRIVER
 M:	Sakari Ailus <sakari.ailus@linux.intel.com>
 L:	linux-media@vger.kernel.org
-- 
2.9.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [V9, 0/2] media: i2c: Add support for OV02A10 sensor
From: Dongchun Zhu @ 2020-05-23  8:41 UTC (permalink / raw)
  To: linus.walleij, bgolaszewski, mchehab, andriy.shevchenko, robh+dt,
	mark.rutland, sakari.ailus, drinkcat, tfiga, matthias.bgg,
	bingbu.cao
  Cc: devicetree, srv_heupstream, shengnan.wang, sj.huang,
	linux-mediatek, dongchun.zhu, louis.kuo, linux-arm-kernel,
	linux-media


Hello,

This series adds DT bindings in YAML and V4L2 sub-device driver for Omnivision's
OV02A10 2 megapixel CMOS 1/5" sensor, which has a single MIPI lane interface(I/F)
and output format of 10-bit RAW.

The driver is implemented with V4L2 Framework.
 - Async registered as one V4L2 sub-device.
 - As the first component of camera system including Seninf/ISP processing pipeline.
 - A media entity that provides one source pad in common and two for dual camera.
 
Previous versions of this patch-set can be found here:
 v8: https://lore.kernel.org/linux-media/20200509080627.23222-1-dongchun.zhu@mediatek.com/
 v7: https://lore.kernel.org/linux-media/20200430080924.1140-1-dongchun.zhu@mediatek.com/
 v6: https://lore.kernel.org/linux-media/20191211112849.16705-1-dongchun.zhu@mediatek.com/
 v5: https://lore.kernel.org/linux-media/20191104105713.24311-1-dongchun.zhu@mediatek.com/
 v4: https://lore.kernel.org/linux-media/20190907092728.23897-1-dongchun.zhu@mediatek.com/
 v3: https://lore.kernel.org/linux-media/20190819034331.13098-1-dongchun.zhu@mediatek.com/
 v2: https://lore.kernel.org/linux-media/20190704084651.3105-1-dongchun.zhu@mediatek.com/
 v1: https://lore.kernel.org/linux-media/20190523102204.24112-1-dongchun.zhu@mediatek.com/

Changes of v9 mainly address comments from Rob, Sakari, Tomasz, Andy.
Including:
 - Add more detailed descriptions for powerdown-gpios and reset-gpios in DT
 - Set default to properties: "rotation" and "ovti,mipi-tx-speed"
 - Remove reserved values of "ovti,mipi-tx-speed"
 - Use ARRAY_SIZE() directly to replace of defining macro function
 - Remove __maybe_unused specifier for ov02a10_power_on and ov02a10_power_off
 - Refine driver by removing unnecessary logs and unused macros or fields.
 - Power off sensor when async register subdev failed and !pm_runtime_enabled()
 - Fix other review comments in v8

Please review.
Thanks.

Dongchun Zhu (2):
  media: dt-bindings: media: i2c: Document OV02A10 bindings
  media: i2c: ov02a10: Add OV02A10 image sensor driver

 .../bindings/media/i2c/ovti,ov02a10.yaml           |  172 ++++
 MAINTAINERS                                        |    8 +
 drivers/media/i2c/Kconfig                          |   13 +
 drivers/media/i2c/Makefile                         |    1 +
 drivers/media/i2c/ov02a10.c                        | 1025 ++++++++++++++++++++
 5 files changed, 1219 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov02a10.yaml
 create mode 100644 drivers/media/i2c/ov02a10.c

-- 
2.9.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: arm64: Register modification during syscall entry/exit stop
From: Keno Fischer @ 2020-05-23  5:35 UTC (permalink / raw)
  To: Will Deacon
  Cc: Catalin Marinas, Kyle Huey, Oleg Nesterov, linux-arm-kernel,
	Linux Kernel Mailing List
In-Reply-To: <20200520174149.GB27629@willie-the-truck>

I got bitten by this again, so I decided to write up a simple example
that shows the problem:

https://gist.github.com/Keno/cde691b26e32373307fb7449ad305739

This runs the same child twice. First vanilla where it prints "Hello world".
The second time, using a textbook ptrace example, to only print "world".
The problem here is that by the time the ptracer gets around to restoring
the registers, it's no longer in a syscall stop, so the write to x7 does not
get ignored and the correct value of x7 gets clobbered.
I copied the syscall definition from musl, so the compiler thinks x7 is
live, and we can see an assertion.

Output on my machine (will depend on compiler version, etc.):
```
$ gcc -g3 -O3 ptrace_lies.c
$ ./a.out
Hello World
World
a.out: ptrace_lies.c:49: do_child: Assertion `v3 == values[2]' failed.
a.out: ptrace_lies.c:134: main: Assertion `WIFEXITED(status) &&
WEXITSTATUS(status) == 0' failed.
Aborted (core dumped)
```

However, I don't think that whether or not the compiler thinks that x7 is
live is the problem here. The problem is entirely that this mechanism
prevents the ptracer from precisely controlling the register state. While
basic ptracers don't need this feature (strace),
more advanced ptracers (think criu, etc.) absolutely do want to precisely
control what the register state is.
The ptracer I'm working on (https://rr-project.org/)
happens to be an extreme case of this, where it wants *bitwise* equivalent
register states such that it can run the same code many times and get
the exact same results.

Also, if the issue was just that the kernel clobbered x7, that would be fine
we could deal with that no problem. However, it's much worse than that,
because the behavior of the kernel with respect to x7 depends on what
kind of ptrace stop we're in and even worse, in some kinds of stop,
there's absolutely no way to get at the actual value of x7.

> Hmm, does that actually result in the SVC instruction getting inlined? I
> think that's quite dangerous, since we document that we can trash the SVE
> register state on a system call, for example. I'm also surprised that
> the register variables are honoured by compilers if that inlining can occur.

I haven't gotten to trying SVE yet, so I appreciate the warning :). That said,
deterministic clobbering of registers is fine. Even changing the registers to
random junk is fine. We're happy to read those registers through ptrace.
The problem here is that the kernel lies about what the contents of the x7
register is and discards any writes to it.

I really hope we can come up with a solution here, I'm already dreading
the next time I unexpectedly run into this and have to add yet
another special case :(.

Keno

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [V8, 2/2] media: i2c: ov02a10: Add OV02A10 image sensor driver
From: Dongchun Zhu @ 2020-05-23  4:50 UTC (permalink / raw)
  To: Tomasz Figa
  Cc: mark.rutland, drinkcat, andriy.shevchenko, srv_heupstream,
	devicetree, linus.walleij, shengnan.wang, louis.kuo, bgolaszewski,
	sj.huang, robh+dt, linux-mediatek, dongchun.zhu, sakari.ailus,
	matthias.bgg, bingbu.cao, mchehab, linux-arm-kernel, linux-media
In-Reply-To: <20200521193204.GA14214@chromium.org>

Hi Tomasz,

Thanks for the review. My replies are as below.

On Thu, 2020-05-21 at 19:32 +0000, Tomasz Figa wrote:
> Hi Dongchun,
> 
> On Sat, May 09, 2020 at 04:06:27PM +0800, Dongchun Zhu wrote:
> > Add a V4L2 sub-device driver for OV02A10 image sensor.
> > 
> > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > ---
> >  MAINTAINERS                 |    1 +
> >  drivers/media/i2c/Kconfig   |   13 +
> >  drivers/media/i2c/Makefile  |    1 +
> >  drivers/media/i2c/ov02a10.c | 1094 +++++++++++++++++++++++++++++++++++++++++++
> >  4 files changed, 1109 insertions(+)
> >  create mode 100644 drivers/media/i2c/ov02a10.c
> > 
> 
> Thank you for the patch. Please see my comments inline.
> 
> [snip]
> > +struct ov02a10 {
> > +	u32			eclk_freq;
> > +	u32                     mipi_clock_tx_speed;
> > +
> > +	struct clk		*eclk;
> > +	struct gpio_desc	*pd_gpio;
> > +	struct gpio_desc	*n_rst_gpio;
> > +	struct regulator_bulk_data supplies[OV02A10_NUM_SUPPLIES];
> > +
> > +	bool			streaming;
> > +	bool			upside_down;
> > +	bool			mipi_clock_tx_speed_select_enable;
> > +	bool			mipi_clock_hs_mode_enable;
> > +
> > +	/*
> > +	 * Serialize control access, get/set format, get selection
> > +	 * and start streaming.
> > +	 */
> > +	struct mutex		mutex;
> > +	struct v4l2_subdev	subdev;
> > +	struct media_pad	pad;
> > +	struct v4l2_ctrl	*anal_gain;
> > +	struct v4l2_ctrl	*exposure;
> > +	struct v4l2_ctrl	*hblank;
> > +	struct v4l2_ctrl	*vblank;
> > +	struct v4l2_ctrl	*test_pattern;
> > +	struct v4l2_mbus_framefmt	fmt;
> 
> nit: Remove the tabs between types and names and use single spaces. As you
> can see above, even tabs don't guarantee equal alignment. And they actually
> make adding fields more difficult, because if a longer field is added, the
> alignment breaks.
> 

Thanks for sharing the rule of adding new fields.
Fixed in next release.

> [snip]
> > +static int ov02a10_read_smbus(struct ov02a10 *ov02a10, unsigned char reg,
> > +			      unsigned char *val)
> > +{
> > +	struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
> > +	int ret;
> > +
> > +	ret = i2c_smbus_read_byte_data(client, reg);
> > +
> 
> nit: Unnecessary blank line.
> 

Sorry for the carelessness.
Fixed in next release.

> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	*val = (unsigned char)ret;
> > +
> > +	return 0;
> > +}
> [snip]
> > +static int __maybe_unused ov02a10_power_on(struct device *dev)
> 
> How is it possible that this function may be unused? If this driver allows
> disabling runtime PM, then there is still a need to configure the clock,
> regulator and GPIO. If not, there shouldn't be a case where this function
> is unused.
> 

Thanks for the reminder.
Modifier __maybe_unused would be removed in next release.

> > +{
> > +	struct i2c_client *client = to_i2c_client(dev);
> > +	struct v4l2_subdev *sd = i2c_get_clientdata(client);
> > +	struct ov02a10 *ov02a10 = to_ov02a10(sd);
> > +	int ret;
> > +
> > +	gpiod_set_value_cansleep(ov02a10->n_rst_gpio, 0);
> > +	gpiod_set_value_cansleep(ov02a10->pd_gpio, 0);
> > +
> > +	ret = clk_prepare_enable(ov02a10->eclk);
> > +	if (ret < 0) {
> > +		dev_err(dev, "failed to enable eclk\n");
> > +		return ret;
> > +	}
> > +
> > +	ret = regulator_bulk_enable(OV02A10_NUM_SUPPLIES, ov02a10->supplies);
> > +	if (ret < 0) {
> > +		dev_err(dev, "failed to enable regulators\n");
> > +		goto disable_clk;
> > +	}
> > +	usleep_range(5000, 6000);
> > +
> > +	gpiod_set_value_cansleep(ov02a10->pd_gpio, 1);
> 
> This is a "powerdown" GPIO. It must be set to 0 if the sensor is to be
> powered on.
> 

The value set by gpiod_set_value_cansleep() API actually depends upon
GPIO polarity defined in DT.
Since I set GPIO_ACTIVE_LOW to powerdown,
gpiod_set_value_cansleep(gpio_desc, value) would set !value to
gpio_desc.
Thus here powerdown would be low-state when sensor is powered on.
For GPIO polarity, I also post a comment to the binding patch.

> > +	usleep_range(5000, 6000);
> > +
> > +	gpiod_set_value_cansleep(ov02a10->n_rst_gpio, 1);
> > +	usleep_range(5000, 6000);
> > +
> > +	ret = ov02a10_check_sensor_id(ov02a10);
> > +	if (ret)
> > +		goto disable_regulator;
> > +
> > +	return 0;
> > +
> > +disable_regulator:
> > +	regulator_bulk_disable(OV02A10_NUM_SUPPLIES, ov02a10->supplies);
> > +disable_clk:
> > +	clk_disable_unprepare(ov02a10->eclk);
> > +
> > +	return ret;
> > +}
> > +
> > +static int __maybe_unused ov02a10_power_off(struct device *dev)
> > +{
> > +	struct i2c_client *client = to_i2c_client(dev);
> > +	struct v4l2_subdev *sd = i2c_get_clientdata(client);
> > +	struct ov02a10 *ov02a10 = to_ov02a10(sd);
> > +
> > +	gpiod_set_value_cansleep(ov02a10->n_rst_gpio, 0);
> > +	clk_disable_unprepare(ov02a10->eclk);
> > +	gpiod_set_value_cansleep(ov02a10->pd_gpio, 0);
> 
> Similar comment as above. To power off the sensor, the "powerdown" GPIO
> needs to be active, i.e. 1.
> 

Similar setting.
It depends upon GPIO polarity.

> [snip]
> > +/*
> > + * ov02a10_set_exposure - Function called when setting exposure time
> > + * @priv: Pointer to device structure
> > + * @val: Variable for exposure time, in the unit of micro-second
> > + *
> > + * Set exposure time based on input value.
> > + *
> > + * Return: 0 on success
> > + */
> > +static int ov02a10_set_exposure(struct ov02a10 *ov02a10, int val)
> > +{
> > +	struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
> > +	int ret;
> > +
> > +	ret = i2c_smbus_write_byte_data(client, REG_PAGE_SWITCH, REG_ENABLE);
> > +	if (ret < 0)
> > +		return ret;
> 
> How does this page switch work? According to the documentation I have, the
> register allows selecting between a few different pages. However, there
> should be two page pointers - one for the AP and the other for the sensor,
> so that when the AP is programming page X, the sensor can have consistent
> settings from page Y. But here we only set one register and always with
> page 1.
> 

Thanks for the carefully observation.
The style or requirement of register setting here is suggested by OV
vendor.
From hardware signal behavior and effect-test, this setting should be
right.
But for your concern, we can also dig into it with OV.
Let's have time to talk with OV.

> > +
> > +	ret = i2c_smbus_write_byte_data(client, OV02A10_REG_EXPOSURE_H,
> > +					val >> OV02A10_EXP_SHIFT);
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	ret = i2c_smbus_write_byte_data(client, OV02A10_REG_EXPOSURE_L, val);
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	return i2c_smbus_write_byte_data(client, REG_GLOBAL_EFFECTIVE,
> > +					 REG_ENABLE);
> 
> This patch defines REG_GLOBAL_EFFECTIVE to 0x01. I don't see such register
> mentioned in the documentation.
> 

There may be several editions of sensor documentation.
From OV, 0x01 is one register shall be updated to keep
exposure/gain/test pattern... register settings effective.

> > +}
> > +
> > +static int ov02a10_set_gain(struct ov02a10 *ov02a10, int val)
> > +{
> > +	struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
> > +	int ret;
> > +
> > +	ret = i2c_smbus_write_byte_data(client, REG_PAGE_SWITCH, REG_ENABLE);
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	ret = i2c_smbus_write_byte_data(client, OV02A10_REG_GAIN, val);
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	return i2c_smbus_write_byte_data(client, REG_GLOBAL_EFFECTIVE,
> > +					 REG_ENABLE);
> > +}
> > +
> > +static int ov02a10_set_vblank(struct ov02a10 *ov02a10, int val)
> > +{
> > +	struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
> > +	u32 vts = val + ov02a10->cur_mode->height - OV02A10_BASIC_LINE;
> > +	int ret;
> > +
> > +	ret = i2c_smbus_write_byte_data(client, REG_PAGE_SWITCH, REG_ENABLE);
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	ret = i2c_smbus_write_byte_data(client, OV02A10_REG_VTS_H,
> > +					vts >> OV02A10_VTS_SHIFT);
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	ret = i2c_smbus_write_byte_data(client, OV02A10_REG_VTS_L, vts);
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	return i2c_smbus_write_byte_data(client, REG_GLOBAL_EFFECTIVE,
> > +					 REG_ENABLE);
> > +}
> > +
> > +static int ov02a10_set_test_pattern(struct ov02a10 *ov02a10, int pattern)
> > +{
> > +	struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
> > +	int ret;
> > +
> > +	if (pattern)
> > +		pattern = OV02A10_TEST_PATTERN_ENABLE;
> 
> Is this necessary? Our control can be 0 for disabled and 1 for color bars.
> The latter is the same as the above macro.
> 

Yes. It looks redundant here.
Fixed in next release.

> [snip]
> > +static int ov02a10_initialize_controls(struct ov02a10 *ov02a10)
> > +{
> > +	struct i2c_client *client = v4l2_get_subdevdata(&ov02a10->subdev);
> > +	const struct ov02a10_mode *mode;
> > +	struct v4l2_ctrl_handler *handler;
> > +	struct v4l2_ctrl *ctrl;
> > +	u64 exposure_max;
> > +	u32 pixel_rate, h_blank;
> > +	int ret;
> > +
> > +	handler = &ov02a10->ctrl_handler;
> > +	mode = ov02a10->cur_mode;
> > +	ret = v4l2_ctrl_handler_init(handler, 7);
> > +	if (ret)
> > +		return ret;
> > +
> > +	handler->lock = &ov02a10->mutex;
> > +
> > +	ctrl = v4l2_ctrl_new_int_menu(handler, NULL, V4L2_CID_LINK_FREQ, 0, 0,
> > +				      link_freq_menu_items);
> > +	if (ctrl)
> > +		ctrl->flags |= V4L2_CTRL_FLAG_READ_ONLY;
> > +
> > +	pixel_rate = to_pixel_rate(0);
> > +	v4l2_ctrl_new_std(handler, NULL, V4L2_CID_PIXEL_RATE, 0, pixel_rate, 1,
> > +			  pixel_rate);
> > +
> > +	h_blank = mode->hts_def - mode->width;
> > +	ov02a10->hblank = v4l2_ctrl_new_std(handler, NULL, V4L2_CID_HBLANK,
> > +					    h_blank, h_blank, 1, h_blank);
> > +	if (ov02a10->hblank)
> > +		ov02a10->hblank->flags |= V4L2_CTRL_FLAG_READ_ONLY;
> > +
> 
> Do we need to hold a pointer to this control? We don't seem to ever access
> it anywhere else in the driver.
> 

No.
These lines would be removed in next release.

> > +	ov02a10->vblank = v4l2_ctrl_new_std(handler, &ov02a10_ctrl_ops,
> > +					    V4L2_CID_VBLANK, mode->vts_def -
> > +					    mode->height,
> > +					    OV02A10_VTS_MAX - mode->height, 1,
> > +					    mode->vts_def - mode->height);
> > +
> 
> Ditto.
> 

These lines would be removed in next release.

> > +	exposure_max = mode->vts_def - 4;
> > +	ov02a10->exposure = v4l2_ctrl_new_std(handler, &ov02a10_ctrl_ops,
> > +					      V4L2_CID_EXPOSURE,
> > +					      OV02A10_EXPOSURE_MIN,
> > +					      exposure_max,
> > +					      OV02A10_EXPOSURE_STEP,
> > +					      mode->exp_def);
> > +
> > +	ov02a10->anal_gain = v4l2_ctrl_new_std(handler, &ov02a10_ctrl_ops,
> > +					       V4L2_CID_ANALOGUE_GAIN,
> > +					       OV02A10_GAIN_MIN,
> > +					       OV02A10_GAIN_MAX,
> > +					       OV02A10_GAIN_STEP,
> > +					       OV02A10_GAIN_DEFAULT);
> 
> Ditto.
> 

Fields: exposure and anal_gain would be removed in next release.
But v4l2_ctrl_new_std remains, as user may set exp/gain. 

> > +
> > +	ov02a10->test_pattern =
> > +		v4l2_ctrl_new_std_menu_items(handler, &ov02a10_ctrl_ops,
> > +					     V4L2_CID_TEST_PATTERN,
> > +					     ARRAY_SIZE(ov02a10_test_pattern_menu) -
> > +					     1, 0, 0,
> > +					     ov02a10_test_pattern_menu);
> 
> Ditto.
> 

Fields: test_pattern would be removed in next release.
But v4l2_ctrl_new_std_menu_items remains.

> [snip]
> > +	ov02a10->pd_gpio = devm_gpiod_get(dev, "powerdown", GPIOD_OUT_HIGH);
> > +	if (IS_ERR(ov02a10->pd_gpio)) {
> > +		ret = PTR_ERR(ov02a10->pd_gpio);
> > +		dev_err(dev, "failed to get powerdown-gpios %d\n", ret);
> > +		return ret;
> > +	}
> > +
> > +	ov02a10->n_rst_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
> 
> I've asked a question about the right convention to define active low pins,
> but I don't remember seeing an answer. We need to clarify this to avoid
> confusion. Especially since the current binding documentation doesn't
> mention anything about the sensor being active low. Let me also post a
> comment to the binding patch.
> 

It depends upon GPIO polarity, however, which may not be emphasized in
current DT version.

> > +	if (IS_ERR(ov02a10->n_rst_gpio)) {
> > +		ret = PTR_ERR(ov02a10->n_rst_gpio);
> > +		dev_err(dev, "failed to get reset-gpios %d\n", ret);
> > +		return ret;
> > +	}
> > +
> > +	for (i = 0; i < OV02A10_NUM_SUPPLIES; i++)
> > +		ov02a10->supplies[i].supply = ov02a10_supply_names[i];
> > +
> > +	ret = devm_regulator_bulk_get(dev, OV02A10_NUM_SUPPLIES,
> > +				      ov02a10->supplies);
> > +	if (ret) {
> > +		dev_err(dev, "failed to get regulators\n");
> > +		return ret;
> > +	}
> > +
> > +	mutex_init(&ov02a10->mutex);
> > +	ov02a10->cur_mode = &supported_modes[0];
> > +	ret = ov02a10_initialize_controls(ov02a10);
> > +	if (ret) {
> > +		dev_err(dev, "failed to initialize controls\n");
> > +		goto err_destroy_mutex;
> > +	}
> > +
> > +	ov02a10->subdev.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> > +	ov02a10->subdev.entity.ops = &ov02a10_subdev_entity_ops;
> > +	ov02a10->subdev.entity.function = MEDIA_ENT_F_CAM_SENSOR;
> > +	ov02a10->pad.flags = MEDIA_PAD_FL_SOURCE;
> > +	ret = media_entity_pads_init(&ov02a10->subdev.entity, 1, &ov02a10->pad);
> > +	if (ret < 0) {
> > +		dev_err(dev, "failed to init entity pads: %d", ret);
> > +		goto err_free_handler;
> > +	}
> > +
> > +	pm_runtime_enable(dev);
> > +	if (!pm_runtime_enabled(dev)) {
> > +		ret = ov02a10_power_on(dev);
> > +		if (ret < 0) {
> > +			dev_err(dev, "failed to power on: %d\n", ret);
> > +			goto err_clean_entity;
> > +		}
> > +	}
> > +
> > +	ret = v4l2_async_register_subdev(&ov02a10->subdev);
> > +	if (ret) {
> > +		dev_err(dev, "failed to register V4L2 subdev: %d", ret);
> > +		goto err_clean_entity;
> > +	}
> > +
> > +	return 0;
> > +
> > +err_clean_entity:
> 
> Need to power off if !pm_runtime_enabled().
> 

Thanks for the reminder.
Fixed in next release by adding power off into err_clean_entity.

> Best regards,
> Tomasz

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [RFC][PATCH 0/2] Add support for using reserved memory for ima buffer pass
From: Thiago Jung Bauermann @ 2020-05-23  4:08 UTC (permalink / raw)
  To: Prakhar Srivastava
  Cc: Mark Rutland, kstewart, gregkh, benh, bhsharma, tao.li, zohar,
	paulus, vincenzo.frascino, will, Rob Herring, nramas,
	frowand.list, masahiroy, jmorris, takahiro.akashi,
	linux-arm-kernel, catalin.marinas, serge, devicetree,
	pasha.tatashin, hsinyi, tusharsu, tglx, allison, christophe.leroy,
	mbrugger, balajib, dmitry.kasatkin, linux-kernel,
	linux-security-module, james.morse, mpe, linux-integrity,
	linuxppc-dev
In-Reply-To: <7701df90-a68b-b710-4279-9d64e45ee792@linux.microsoft.com>


Hello Prakhar,

Prakhar Srivastava <prsriva@linux.microsoft.com> writes:

> On 5/12/20 4:05 PM, Rob Herring wrote:
>> On Wed, May 06, 2020 at 10:50:04PM -0700, Prakhar Srivastava wrote:
>>> Hi Mark,
>>
>> Please don't top post.
>>
>>> This patch set currently only address the Pure DT implementation.
>>> EFI and ACPI implementations will be posted in subsequent patchsets.
>>>
>>> The logs are intended to be carried over the kexec and once read the
>>> logs are no longer needed and in prior conversation with James(
>>> https://lore.kernel.org/linux-arm-kernel/0053eb68-0905-4679-c97a-00c5cb6f1abb@arm.com/)
>>> the apporach of using a chosen node doesn't
>>> support the case.
>>>
>>> The DT entries make the reservation permanent and thus doesnt need kernel
>>> segments to be used for this, however using a chosen-node with
>>> reserved memory only changes the node information but memory still is
>>> reserved via reserved-memory section.
>>
>> I think Mark's point was whether it needs to be permanent. We don't
>> hardcode the initrd address for example.
>>
> Thankyou for clarifying my misunderstanding, i am modelling this keeping to the
> TPM log implementation that uses a reserved memory. I will rev up the version
> with chosen-node support.
> That will make the memory reservation free after use.

Nice. Do you intend to use the same property that powerpc uses
(linux,ima-kexec-buffer)?

>>> On 5/5/20 2:59 AM, Mark Rutland wrote:
>>>> Hi Prakhar,
>>>>
>>>> On Mon, May 04, 2020 at 01:38:27PM -0700, Prakhar Srivastava wrote:
>>>>> IMA during kexec(kexec file load) verifies the kernel signature and measures
>>
>> What's IMAIMA is a LSM attempting to detect if files have been accidentally or
> maliciously altered, both remotely and locally, it can also be used
> to appraise a file's measurement against a "good" value stored as an extended
> attribute, and enforce local file integrity.
>
> IMA also validates and measures the signers of the kernel and initrd
> during kexec. The measurements are extended to PCR 10(configurable) and the logs
> stored in memory, however once kexec'd the logs are lost. Kexec is used as
> secondary boot loader in may use cases and loosing the signer
> creates a security hole.
>
> This patch is an implementation to carry over the logs and making it
> possible to remotely validate the signers of the kernel and initrd. Such a
> support exits only in powerpc.
> This patch makes the carry over of logs architecture independent and puts the
> complexity in a driver.

If I'm not mistaken, the code at arch/powerpc/kexec/ima.c isn't actually
powerpc-specific. It could be moved to an arch-independent directory and
used by any other architecture which supports device trees.

I think that's the simplest way forward. And to be honest I'm still
trying to understand why you didn't take that approach. Did you try it
and hit some obstacle or noticed a disadvantage for your use case?

--
Thiago Jung Bauermann
IBM Linux Technology Center

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [GIT PULL 6/6] i.MX defconfig update for 5.8
From: Shawn Guo @ 2020-05-23  3:25 UTC (permalink / raw)
  To: soc, arm
  Cc: Shawn Guo, Stefan Agner, Li Yang, linux-imx, kernel,
	Fabio Estevam, linux-arm-kernel
In-Reply-To: <20200523032516.11016-1-shawnguo@kernel.org>

The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:

  Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-defconfig-5.8

for you to fetch changes up to 5b4bf802427e3f49b9bca5e02ec7154e4d3d63ad:

  ARM: imx_v6_v7_defconfig: extend RN5T618 PMIC family support (2020-05-20 09:29:07 +0800)

----------------------------------------------------------------
i.MX defconfig update for 5.8:

- Enable RTC and ADC support of RN5T618 PMIC in imx_v6_v7_defconfig.
- Enable i.MX8DXL pinctrl driver support in arm64 defconfig.

----------------------------------------------------------------
Andreas Kemnade (1):
      ARM: imx_v6_v7_defconfig: extend RN5T618 PMIC family support

Anson Huang (1):
      arm64: defconfig: Enable CONFIG_PINCTRL_IMX8DXL by default

 arch/arm/configs/imx_v6_v7_defconfig | 2 ++
 arch/arm64/configs/defconfig         | 1 +
 2 files changed, 3 insertions(+)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [GIT PULL 5/6] i.MX arm64 device tree changes for 5.8
From: Shawn Guo @ 2020-05-23  3:25 UTC (permalink / raw)
  To: soc, arm
  Cc: Shawn Guo, Stefan Agner, Li Yang, linux-imx, kernel,
	Fabio Estevam, linux-arm-kernel
In-Reply-To: <20200523032516.11016-1-shawnguo@kernel.org>

The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:

  Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-dt64-5.8

for you to fetch changes up to 48ffd4ebc1daf7eac054cf282ed0c2632abc2e20:

  arm64: dts: Add ds26522 node to dts to ls1043ardb (2020-05-20 23:00:47 +0800)

----------------------------------------------------------------
i.MX arm64 device tree changes:

- New support of Beacon i.MX8m-Mini development kit.
- Add secondary cpus supply on imx8mm-evk and imx8mn-ddr4-evk for
  completeness.
- Add thermal zones for imx8mp and lx2160a, PMIC thermal zone for
  imx8qxp-mek board.
- Update VDD_ARM 1.2GHz setpoint voltage for imx8mn.
- Add SRC device interrupt for i.MX8 SoCs.
- Use 0.9V for VDD_GPU on imx8mq-librem5-devkit, since there is no need
  to support overclocking to 1GHz.
- Update imx8qxp SCU device to use MU channel with less interrupt
  triggering, one RX interrupt for a RX and one TX interrupt for a TX.
- Specify DMA channels for LS1028A DSPI controllers.
- Add QE and DS26522 device support for fsl-ls1043a-rdb board.
- Misc random update and cleanup.

----------------------------------------------------------------
Adam Ford (1):
      arm64: dts: imx: Add Beacon i.MX8m-Mini development kit

Anson Huang (8):
      arm64: dts: imx8mm-evk: Add secondary cpus supply
      arm64: dts: imx8mn-ddr4-evk: Add secondary cpus supply
      arm64: dts: imx8mp: Add thermal zones support
      arm64: dts: imx8qxp-mek: Sort labels alphabetically
      arm64: dts: imx8qxp-mek: Add PMIC thermal zone support
      arm64: dts: imx8mn: Update VDD_ARM 1.2GHz setpoint voltage
      arm64: dts: imx8mq: Add src node interrupts
      arm64: dts: imx8mp: Add src node interrupts

Fabio Estevam (1):
      arm64: dts: imx8qxp-mek: Do not use underscore in node name

Fugang Duan (1):
      arm64: dts: imx8mp: add "fsl,imx6sx-fec" compatible string

Guido Günther (2):
      arm64: dts: imx8mq-librem5-devkit: Use 0.9V for VDD_GPU
      arm64: dts: imx8mq-librem5-devkit: Don't use underscore in node name

Kuldeep Singh (1):
      arm64: dts: ls1012a: Add QSPI node properties

Matt Porter (1):
      arm64: dts: imx8mm: specify #sound-dai-cells for SAI nodes

Michael Walle (2):
      arm64: dts: freescale: sl28: enable LPUART1
      arm64: dts: ls1028a: sl28: keep switch port names consistent

Peng Fan (2):
      arm64: dts: imx8qxp: support scu mailbox channel
      arm64: dts: imx8m: assign clocks for A53

Vladimir Oltean (1):
      arm64: dts: ls1028a: Specify the DMA channels for the DSPI controllers

Yangbo Lu (2):
      arm64: dts: fsl: add fsl,extts-fifo property for fman ptp
      arm64: dts: ls1043a-rdb: add compatible for board

Yuantian Tang (1):
      arm64: dts: lx2160a: add more thermal zone support

Zhao Qiang (2):
      arm64: dts: add qe node to ls1043ardb
      arm64: dts: Add ds26522 node to dts to ls1043ardb

 arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts |  15 +
 arch/arm64/boot/dts/freescale/fsl-ls1012a-frwy.dts |  15 +
 arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts  |  15 +
 arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts  |  15 +
 arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi     |  13 +
 .../freescale/fsl-ls1028a-kontron-sl28-var2.dts    |   4 +-
 .../dts/freescale/fsl-ls1028a-kontron-sl28.dts     |   5 +
 arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi     |   6 +
 arch/arm64/boot/dts/freescale/fsl-ls1043a-rdb.dts  |  33 ++
 arch/arm64/boot/dts/freescale/fsl-ls1043a.dtsi     |  65 ++++
 arch/arm64/boot/dts/freescale/fsl-lx2160a.dtsi     | 130 ++++++-
 .../dts/freescale/imx8mm-beacon-baseboard.dtsi     | 285 ++++++++++++++
 .../arm64/boot/dts/freescale/imx8mm-beacon-kit.dts |  19 +
 .../boot/dts/freescale/imx8mm-beacon-som.dtsi      | 410 +++++++++++++++++++++
 arch/arm64/boot/dts/freescale/imx8mm-evk.dts       |  12 +
 arch/arm64/boot/dts/freescale/imx8mm.dtsi          |  14 +-
 arch/arm64/boot/dts/freescale/imx8mn-ddr4-evk.dts  |  12 +
 arch/arm64/boot/dts/freescale/imx8mn.dtsi          |  12 +-
 arch/arm64/boot/dts/freescale/imx8mp.dtsi          |  88 ++++-
 .../boot/dts/freescale/imx8mq-librem5-devkit.dts   |   4 +-
 arch/arm64/boot/dts/freescale/imx8mq.dtsi          |  10 +-
 arch/arm64/boot/dts/freescale/imx8qxp-mek.dts      |  95 +++--
 arch/arm64/boot/dts/freescale/imx8qxp.dtsi         |  18 +-
 arch/arm64/boot/dts/freescale/qoriq-fman3-0.dtsi   |   1 +
 24 files changed, 1231 insertions(+), 65 deletions(-)
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-beacon-baseboard.dtsi
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-beacon-kit.dts
 create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [GIT PULL 4/6] i.MX device tree changes for 5.8
From: Shawn Guo @ 2020-05-23  3:25 UTC (permalink / raw)
  To: soc, arm
  Cc: Shawn Guo, Stefan Agner, Li Yang, linux-imx, kernel,
	Fabio Estevam, linux-arm-kernel
In-Reply-To: <20200523032516.11016-1-shawnguo@kernel.org>

The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:

  Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-dt-5.8

for you to fetch changes up to 103515d91832bb837159c37f0cb69d59d68a1dc2:

  ARM: dts: imx53-cx9020: Group port definitions for the dvi-converter (2020-05-20 10:57:14 +0800)

----------------------------------------------------------------
i.MX device tree changes for 5.8:

- A series from Anson Huang updating SRC devices to match bindings
  schema definition.
- Correct CPU supply name and add cpu1 supply for i.MX7D.
- Convert thermal device to use nvmem interface to get fuse data
  for imx6qdl and imx6sl.
- A series from Tim Harvey to update imx6qdl-gw devices, adding support
  of LSM9DS1 IIO imu/magn, USB OTG, bcm4330-bt, etc.
- Add input MUX for ENET2 MDIO into IMX7D pin functions.
- Misc random device addition or update.

----------------------------------------------------------------
Andreas Kemnade (1):
      ARM: dts: e60k02: add interrupt for PMIC

Anson Huang (9):
      ARM: dts: imx7: Correct CPU supply name
      ARM: dts: imx7d: Add cpu1 supply
      ARM: dts: imx51: Add src node interrupt
      ARM: dts: imx53: Add src node interrupt
      ARM: dts: imx6qdl: Use nvmem interface to get fuse data
      ARM: dts: imx6sl: Use nvmem interface to get fuse data
      ARM: dts: imx: make src node name generic
      ARM: dts: imx50: Add src node interrupt
      ARM: dts: imx5: make src node name generic

Fabio Estevam (1):
      ARM: dts: imx50: Remove unused iomuxc-gpr node

Igor Opaniuk (1):
      ARM: dts: colibri: introduce device trees with UHS-I support

Kuldeep Singh (1):
      arm: dts: ls1021atwr: Add QSPI node properties

Marek Vasut (1):
      ARM: dts: imx6q-dhcom: Add DH 560-200 display unit support

Ricardo Cañuelo (1):
      ARM: dts: imx53-cx9020: Group port definitions for the dvi-converter

Russell King (1):
      ARM: dts: imx6-sr-som: add ethernet PHY configuration

Steffen Trumtrar (1):
      ARM: dts: imx7d-pinfunc: add input mux for ENET2 mdio

Tim Harvey (5):
      ARM: dts: imx6qdl-gw552x: add USB OTG support
      ARM: dts: imx6qdl-gw560x: add lsm9ds1 iio imu/magn support
      ARM: dts: imx6qdl-gw5904: add lsm9ds1 iio imu/magn support
      ARM: dts: imx6qdl-gw5910: add support for bcm4330-bt
      ARM: dts: imx6qdl-gw5910: fix wlan regulator

 arch/arm/boot/dts/Makefile                        |   1 +
 arch/arm/boot/dts/e60k02.dtsi                     |   2 +
 arch/arm/boot/dts/imx50.dtsi                      |   8 +-
 arch/arm/boot/dts/imx51.dtsi                      |   3 +-
 arch/arm/boot/dts/imx53-cx9020.dts                |  25 ++---
 arch/arm/boot/dts/imx53.dtsi                      |   3 +-
 arch/arm/boot/dts/imx6dl-colibri-v1_1-eval-v3.dts |  31 ++++++
 arch/arm/boot/dts/imx6q-dhcom-pdk2.dts            | 115 +++++++++++++++++++++-
 arch/arm/boot/dts/imx6qdl-colibri-v1_1-uhs.dtsi   |  44 +++++++++
 arch/arm/boot/dts/imx6qdl-colibri.dtsi            |  11 ++-
 arch/arm/boot/dts/imx6qdl-gw552x.dtsi             |  14 +++
 arch/arm/boot/dts/imx6qdl-gw560x.dtsi             |  31 ++++++
 arch/arm/boot/dts/imx6qdl-gw5904.dtsi             |  31 ++++++
 arch/arm/boot/dts/imx6qdl-gw5910.dtsi             |  35 +++----
 arch/arm/boot/dts/imx6qdl-sr-som.dtsi             |  11 +++
 arch/arm/boot/dts/imx6qdl.dtsi                    |  13 ++-
 arch/arm/boot/dts/imx6sl.dtsi                     |  13 ++-
 arch/arm/boot/dts/imx6sx.dtsi                     |   2 +-
 arch/arm/boot/dts/imx6ul.dtsi                     |   2 +-
 arch/arm/boot/dts/imx7-tqma7.dtsi                 |   2 +-
 arch/arm/boot/dts/imx7d-cl-som-imx7.dts           |   4 +
 arch/arm/boot/dts/imx7d-colibri.dtsi              |   4 +
 arch/arm/boot/dts/imx7d-nitrogen7.dts             |   4 +
 arch/arm/boot/dts/imx7d-pinfunc.h                 |   2 +-
 arch/arm/boot/dts/imx7d-sdb.dts                   |   4 +
 arch/arm/boot/dts/imx7d-tqma7.dtsi                |   4 +
 arch/arm/boot/dts/imx7d-zii-rmu2.dts              |   2 +-
 arch/arm/boot/dts/imx7d-zii-rpu2.dts              |   2 +-
 arch/arm/boot/dts/imx7s.dtsi                      |   2 +-
 arch/arm/boot/dts/ls1021a-twr.dts                 |  14 +++
 30 files changed, 384 insertions(+), 55 deletions(-)
 create mode 100644 arch/arm/boot/dts/imx6dl-colibri-v1_1-eval-v3.dts
 create mode 100644 arch/arm/boot/dts/imx6qdl-colibri-v1_1-uhs.dtsi

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [GIT PULL 3/6] i.MX bindings change for 5.8
From: Shawn Guo @ 2020-05-23  3:25 UTC (permalink / raw)
  To: soc, arm
  Cc: Shawn Guo, Stefan Agner, Li Yang, linux-imx, kernel,
	Fabio Estevam, linux-arm-kernel
In-Reply-To: <20200523032516.11016-1-shawnguo@kernel.org>

The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:

  Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-bindings-5.8

for you to fetch changes up to 9c4b24db828a560789bfe8f58495f9df5bfe36b0:

  dt-bindings: arm: imx: add kontron smarc to schema (2020-04-25 09:53:11 +0800)

----------------------------------------------------------------
i.MX bindings change for 5.8:

- Add Kontron SMARC module compatibles to DT schema.
- Add Colibri iMX6S/DL V1.1x devicetree compatibles.

----------------------------------------------------------------
Igor Opaniuk (1):
      dt-bindings: arm: fsl: add nxp based toradex colibri bindings

Marco Felsch (1):
      dt-bindings: arm: imx: add kontron smarc to schema

 Documentation/devicetree/bindings/arm/fsl.yaml | 4 ++++
 1 file changed, 4 insertions(+)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [GIT PULL 2/6] i.MX SoC changes for 5.8
From: Shawn Guo @ 2020-05-23  3:25 UTC (permalink / raw)
  To: soc, arm
  Cc: Shawn Guo, Stefan Agner, Li Yang, linux-imx, kernel,
	Fabio Estevam, linux-arm-kernel
In-Reply-To: <20200523032516.11016-1-shawnguo@kernel.org>

The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:

  Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-soc-5.8

for you to fetch changes up to 52102a3ba6a617449f4b057880d73be93310a7c7:

  soc: imx: move cpu code to drivers/soc/imx (2020-05-20 23:03:50 +0800)

----------------------------------------------------------------
i.MX SoC changes for 5.8:

- Add soc device support for Vybrid/VF platform.
- Move the i.MX soc device registration code from mach-imx to
  drivers/soc/imx for possible future consolidation with i.MX8 code.
- A small fixup to make pcm970_sja1000_platform_data static.

----------------------------------------------------------------
Andrey Smirnov (1):
      ARM: vf610: report soc info via soc device

Ma Feng (1):
      ARM: imx: pcm037: make pcm970_sja1000_platform_data static

Peng Fan (3):
      ARM: imx: use device_initcall for imx_soc_device_init
      ARM: imx: move cpu definitions into a header
      soc: imx: move cpu code to drivers/soc/imx

 arch/arm/mach-imx/common.h       |   1 -
 arch/arm/mach-imx/cpu.c          | 159 --------------------------------
 arch/arm/mach-imx/mach-imx6q.c   |   8 +-
 arch/arm/mach-imx/mach-imx6sl.c  |   8 +-
 arch/arm/mach-imx/mach-imx6sx.c  |   8 +-
 arch/arm/mach-imx/mach-imx6ul.c  |   8 +-
 arch/arm/mach-imx/mach-imx7d.c   |   6 --
 arch/arm/mach-imx/mach-imx7ulp.c |   2 +-
 arch/arm/mach-imx/mach-pcm037.c  |   2 +-
 arch/arm/mach-imx/mach-vf610.c   |  47 ++++++++++
 arch/arm/mach-imx/mxc.h          |  22 +----
 drivers/soc/imx/Makefile         |   3 +
 drivers/soc/imx/soc-imx.c        | 192 +++++++++++++++++++++++++++++++++++++++
 include/soc/imx/cpu.h            |  36 ++++++++
 14 files changed, 285 insertions(+), 217 deletions(-)
 create mode 100644 drivers/soc/imx/soc-imx.c
 create mode 100644 include/soc/imx/cpu.h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [GIT PULL 1/6] i.MX drivers update for 5.8
From: Shawn Guo @ 2020-05-23  3:25 UTC (permalink / raw)
  To: soc, arm
  Cc: Shawn Guo, Stefan Agner, Li Yang, linux-imx, kernel,
	Fabio Estevam, linux-arm-kernel

The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:

  Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-drivers-5.8

for you to fetch changes up to 89f12d6509bff004852c51cb713a439a86816b24:

  firmware: imx: scu: Fix possible memory leak in imx_scu_probe() (2020-05-20 11:33:08 +0800)

----------------------------------------------------------------
i.MX drivers update for 5.8:

- Optimize imx-scu driver to use one TX and one RX instead of four for
  talking to SCU.
- Fix one possible message header corruption where the response is
  longer than the request.
- Move System Control defines into dt-bindings header, so that DT can
  use them as well.
- A couple of small fixups.

----------------------------------------------------------------
Anson Huang (1):
      soc: imx8m: No need to put node when of_find_compatible_node() failed

Dong Aisheng (2):
      dt-bindings: firmware: imx: Move system control into dt-binding headfile
      dt-bindings: firmware: imx: Add more system controls and PM clock types

Franck LENORMAND (1):
      firmware: imx: scu: Fix corruption of header

Peng Fan (1):
      firmware: imx-scu: Support one TX and one RX

Wei Yongjun (1):
      firmware: imx: scu: Fix possible memory leak in imx_scu_probe()

 drivers/firmware/imx/imx-scu.c          | 64 ++++++++++++++++++-------
 drivers/soc/imx/soc-imx8m.c             |  7 ++-
 drivers/thermal/imx_sc_thermal.c        |  2 +-
 include/dt-bindings/firmware/imx/rsrc.h | 84 +++++++++++++++++++++++++++++++++
 include/linux/firmware/imx/sci.h        |  1 -
 include/linux/firmware/imx/types.h      | 65 -------------------------
 6 files changed, 136 insertions(+), 87 deletions(-)
 delete mode 100644 include/linux/firmware/imx/types.h

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* Re: [PATCH v4 3/8] spi: stm32: Add 'SPI_SIMPLEX_RX', 'SPI_3WIRE_RX' support for stm32f4
From: dillon min @ 2020-05-23  1:35 UTC (permalink / raw)
  To: Mark Brown
  Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
	p.zabel, Dave Airlie, Michael Turquette, linux-clk, linux-kernel,
	open list:DRM PANEL DRIVERS, linux-spi, Stephen Boyd, Rob Herring,
	thierry.reding, Maxime Coquelin, Daniel Vetter, Sam Ravnborg,
	linux-stm32, Linux ARM, Alexandre Torgue
In-Reply-To: <20200522162901.GP5801@sirena.org.uk>

On Sat, May 23, 2020 at 12:29 AM Mark Brown <broonie@kernel.org> wrote:
>
> On Fri, May 22, 2020 at 11:59:25PM +0800, dillon min wrote:
>
> > but, after spi-core create a dummy tx_buf or rx_buf, then i can't get
> > the correct spi_3wire direction.
> > actually, this dummy tx_buf is useless for SPI_3WIRE. it's has meaning
> > for SPI_SIMPLE_RX mode,
> > simulate SPI_FULL_DUMPLEX
>
> Oh, that's annoying.  I think the fix here is in the core, it should
> ignore MUST_TX and MUST_RX in 3WIRE mode since they clearly make no
> sense there.

How about add below changes to spi-core

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 8994545..bfd465c 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1022,7 +1022,8 @@ static int spi_map_msg(struct spi_controller
*ctlr, struct spi_message *msg)
        void *tmp;
        unsigned int max_tx, max_rx;

-       if (ctlr->flags & (SPI_CONTROLLER_MUST_RX | SPI_CONTROLLER_MUST_TX)) {
+       if ((ctlr->flags & (SPI_CONTROLLER_MUST_RX | SPI_CONTROLLER_MUST_TX)) &&
+               !(msg->spi->mode & SPI_3WIRE)) {
                max_tx = 0;
                max_rx = 0;

for my board, lcd panel ilitek ill9341 use 3wire mode, gyro l3gd20 use
simplex rx mode.
it's has benefits to l3gd20, no impact to ili9341.

if it's fine to spi-core, i will include it to my next submits.

thanks

best regards.

Dillon

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* Re: [PATCH v4 07/14] PCI: cadence: Add new *ops* for CPU addr fixup
From: Kishon Vijay Abraham I @ 2020-05-23  1:24 UTC (permalink / raw)
  To: Rob Herring
  Cc: devicetree, Lorenzo Pieralisi, Arnd Bergmann, Greg Kroah-Hartman,
	linux-kernel@vger.kernel.org, Tom Joseph, PCI, Bjorn Helgaas,
	linux-omap,
	moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAL_Jsq+qcgKvauJ-GjsnmmpmRusyEJ6pRDpBOQKOadig4XfsxQ@mail.gmail.com>

Hi Rob,

On 5/22/2020 10:15 PM, Rob Herring wrote:
> On Thu, May 21, 2020 at 5:35 AM Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>
>> Hi Rob,
>>
>> On 5/21/2020 3:04 AM, Rob Herring wrote:
>>> On Wed, May 06, 2020 at 08:44:22PM +0530, Kishon Vijay Abraham I wrote:
>>>> Cadence driver uses "mem" memory resource to obtain the offset of
>>>> configuration space address region, memory space address region and
>>>> message space address region. The obtained offset is used to program
>>>> the Address Translation Unit (ATU). However certain platforms like TI's
>>>> J721E SoC require the absolute address to be programmed in the ATU and not
>>>> just the offset.
>>>
>>> Once again, Cadence host binding is broken (or at least the example is).
>>> The 'mem' region shouldn't even exist. It is overlapping the config
>>> space and 'ranges':
>>>
>>>             reg = <0x0 0xfb000000  0x0 0x01000000>,
>>>                   <0x0 0x41000000  0x0 0x00001000>,
>>>                   <0x0 0x40000000  0x0 0x04000000>;
>>>             reg-names = "reg", "cfg", "mem";
>>>
>>>             ranges = <0x02000000 0x0 0x42000000  0x0 0x42000000  0x0 0x1000000>,
>>>                      <0x01000000 0x0 0x43000000  0x0 0x43000000  0x0 0x0010000>;
>>>
>>>
>>> 16M of registers looks a bit odd. I guess it doesn't matter
>>> unless you have a 32-bit platform and care about your virtual
>>> space. Probably should have been 3 regions for LM, RP, and AT looking
>>> at the driver.
>>
>> The "mem" region in never ioremapped. However $patch removes requiring to add
>> "mem" memory resource.
> 
> I was referring to ioremapping 'reg' region.
> 
>>>
>>> Whatever outbound address translation you need should be based on
>>> 'ranges'.
>>
>> You mean we don't need to add "new *ops* for CPU addr fixup"?. The issue is
>> ranges provides CPU address and PCI address. The CPU will access whatever is
>> populated in ranges to access the PCI bus. However while programming the ATU,
>> we cannot use the CPU address provided in ranges directly (in some platforms)
>> because the controller does not see the full address and only the lower 28bits.
> 
> Okay, that is clearer as to what the difference is. I think this
> should be 2 patches. One dropping 'mem' usage and using a mask and the
> 2nd making the mask per platform.

hmm okay.
> 
> Really, the parent node of the PCI controller should probably have
> 'ranges' and you could extract a mask from that. Looks like that is
> what you had for DRA7... I'm not sure if ABI stability is important
> for the Cadence platform. I'd assume that's just some IP eval system
> and probably not?

Right TI's J721E should be the first HW platform to use Cadence in mainline.
> 
> Why do you need an ops here? All you need is a mask value.

So how do we get platform specific mask? Use a different binding to specify the
mask value?
> 
>> This similar restriction was there with Designware (mostly an integration
>> issue) and we used *ops* to fixup the address that has to be programmed in ATU.
>> The Designware initially used a wrapper so that ranges property can be directly
>> used [1]. However this approach was later removed in [2]
>>
>> [1] -> https://lore.kernel.org/patchwork/patch/468523/
>> [2] -> https://lkml.org/lkml/2015/10/16/232
> 
> So while you had the data for a mask in DT, the driver now hardcodes it?

Yes, that's correct. Which approach should we use for Cadence?

Thanks
Kishon

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [GIT PULL] i.MX clock updates for 5.8
From: Shawn Guo @ 2020-05-23  1:07 UTC (permalink / raw)
  To: Stephen Boyd
  Cc: Stefan Agner, linux-imx, kernel, Fabio Estevam, linux-clk,
	linux-arm-kernel

The following changes since commit 8f3d9f354286745c751374f5f1fcafee6b3f3136:

  Linux 5.7-rc1 (2020-04-12 12:35:55 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/clk-imx-5.8

for you to fetch changes up to b1657ad708f761f9ca6d166d4dda685ca39b1254:

  clk: imx: use imx8m_clk_hw_composite_bus for i.MX8M bus clk slice (2020-05-21 22:37:48 +0800)

----------------------------------------------------------------
i.MX clock updates for 5.8:

- A few patches from Abel Vesa as preparation of adding audiomix clock
  support.
- A couple of cleanups from Anson Huang on clk-sscg-pll and clk-pllv3
  driver.
- Update imx7ulp clock driver to use imx_clk_hw_cpu() for making the
  change of ARM core clock easier.
- Drop dependency on ARM64 for i.MX8M clock driver, as there is a move
  to support aarch32 mode on aarch64 hardware.
- A series from Peng Fan to improve i.MX8M clock drivers, using
  composite clock for core and bus clk slice.
- Set a better parent clock for flexcan on i.MX6UL to support CiA102
  defined bit rates.

----------------------------------------------------------------
Abel Vesa (4):
      clk: imx: gate2: Allow single bit gating clock
      clk: imx: pll14xx: Add the device as argument when registering
      clk: imx: Add helpers for passing the device as argument
      dt-bindings: clocks: imx8mp: Add ids for audiomix clocks

Anson Huang (2):
      clk: imx: clk-sscg-pll: Remove unnecessary blank lines
      clk: imx: clk-pllv3: Use readl_relaxed_poll_timeout() for PLL lock wait

Peng Fan (10):
      clk: imx7ulp: make it easy to change ARM core clk
      clk: imx: drop the dependency on ARM64 for i.MX8M
      clk: imx8m: drop clk_hw_set_parent for A53
      clk: imx: imx8mp: fix pll mux bit
      clk: imx8mp: Define gates for pll1/2 fixed dividers
      clk: imx8mp: use imx8m_clk_hw_composite_core to simplify code
      clk: imx8m: migrate A53 clk root to use composite core
      clk: imx: add mux ops for i.MX8M composite clk
      clk: imx: add imx8m_clk_hw_composite_bus
      clk: imx: use imx8m_clk_hw_composite_bus for i.MX8M bus clk slice

Waibel Georg (1):
      clk: imx: imx6ul: change flexcan clock to support CiA bitrates

 drivers/clk/imx/Kconfig                   |   8 +-
 drivers/clk/imx/clk-composite-8m.c        |  56 ++++++++++-
 drivers/clk/imx/clk-gate2.c               |  31 +++++--
 drivers/clk/imx/clk-imx6ul.c              |   2 +-
 drivers/clk/imx/clk-imx7ulp.c             |   6 +-
 drivers/clk/imx/clk-imx8mm.c              |  27 +++---
 drivers/clk/imx/clk-imx8mn.c              |  25 +++--
 drivers/clk/imx/clk-imx8mp.c              | 148 +++++++++++++++---------------
 drivers/clk/imx/clk-imx8mq.c              |  29 +++---
 drivers/clk/imx/clk-pll14xx.c             |   8 +-
 drivers/clk/imx/clk-pllv3.c               |  16 +---
 drivers/clk/imx/clk-sscg-pll.c            |  10 --
 drivers/clk/imx/clk.h                     |  62 ++++++++++++-
 include/dt-bindings/clock/imx7ulp-clock.h |   5 +-
 include/dt-bindings/clock/imx8mp-clock.h  |  90 +++++++++++++++++-
 15 files changed, 358 insertions(+), 165 deletions(-)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* RE: [PATCH] thermal: imx8mm: Add get_trend ops
From: Anson Huang @ 2020-05-23  0:35 UTC (permalink / raw)
  To: Daniel Lezcano, rui.zhang@intel.com, amit.kucheria@verdurent.com,
	shawnguo@kernel.org, s.hauer@pengutronix.de,
	kernel@pengutronix.de, festevam@gmail.com,
	linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
  Cc: dl-linux-imx
In-Reply-To: <fccf4197-d0ca-f313-8f70-000ef4731033@linaro.org>

Hi, Daniel


> Subject: Re: [PATCH] thermal: imx8mm: Add get_trend ops
> 
> On 13/05/2020 04:58, Anson Huang wrote:
> > Add get_trend ops for i.MX8MM thermal to apply fast cooling mechanism,
> > when temperature exceeds passive trip point, the highest cooling
> > action will be applied, and when temperature drops to lower than the
> > margin below passive trip point, the lowest cooling action will be
> > applied.
> 
> You are not describing what is the goal of this change.

The goal of this change is to make sure whenever temperature exceeds passive trip point,
the highest cooling action will be applied immediately, e.g., if there are many cpufreq OPP,
the default cooling will be step by step, it will take some more rounds to make cpufreq drop
to lowest OPP, while on i.MX, we expect the cpufreq drop to lowest OPP immediately.

> 
> IIUC, the resulting change will be an on/off action. The thermal zone is
> mitigated with the highest cooling effect, so the lowest OPP, then the
> temperature trend is stable until it goes below the trip - margin where the
> mitigation is stopped.

Yes, your understanding is correctly, once the temperature exceeds passive trip point,
the highest cooling action will be applied immediately and then it will be stable there
until temperature drop to trip - margin, then the cooling action will be cancelled, the
margin is to avoid the back and forth near the passive trip point.

> 
> Except, I'm missing something, setting a trip point with a 10000 hysteresis and
> a cooling map min/max set to the highest opp will result on the same.

Yes setting cooling map min/max cooling state to highest OPP will make the highest
cooling action applied immediately, and to have the function of cooling action being
cancelled when temperature drops to trip - margin, I have to define another trip point,
say passive trip point is 85000, and cooling map min/max set to highest OPP in passive
trip point then add another trip point named "active" with 75000, and without any
cooling map in it, right?

If yes, then I think I can try to make the changes in DT instead of thermal driver. 

Thanks,
Anson
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH 15/15] PCI: xilinx: Use pci_host_probe() to register host
From: Rob Herring @ 2020-05-22 23:48 UTC (permalink / raw)
  To: Lorenzo Pieralisi
  Cc: Bjorn Helgaas, linux-pci, Michal Simek, linux-arm-kernel
In-Reply-To: <20200522234832.954484-1-robh@kernel.org>

The xilinx host driver does the same host registration and bus scanning
calls as pci_host_probe, so let's use it instead.

The only difference is pci_assign_unassigned_bus_resources() was called
instead of pci_bus_size_bridges() and pci_bus_assign_resources(). This
should be the same.

Cc: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Rob Herring <robh@kernel.org>
---
 drivers/pci/controller/pcie-xilinx.c | 13 +------------
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/pci/controller/pcie-xilinx.c b/drivers/pci/controller/pcie-xilinx.c
index 98e55297815b..05547497f391 100644
--- a/drivers/pci/controller/pcie-xilinx.c
+++ b/drivers/pci/controller/pcie-xilinx.c
@@ -616,7 +616,6 @@ static int xilinx_pcie_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	struct xilinx_pcie_port *port;
-	struct pci_bus *bus, *child;
 	struct pci_host_bridge *bridge;
 	int err;
 
@@ -663,17 +662,7 @@ static int xilinx_pcie_probe(struct platform_device *pdev)
 	xilinx_pcie_msi_chip.dev = dev;
 	bridge->msi = &xilinx_pcie_msi_chip;
 #endif
-	err = pci_scan_root_bus_bridge(bridge);
-	if (err < 0)
-		return err;
-
-	bus = bridge->bus;
-
-	pci_assign_unassigned_bus_resources(bus);
-	list_for_each_entry(child, &bus->children, node)
-		pcie_bus_configure_settings(child);
-	pci_bus_add_devices(bus);
-	return 0;
+	return pci_host_probe(bridge);
 }
 
 static const struct of_device_id xilinx_pcie_of_match[] = {
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH 13/15] PCI: rockchip: Use pci_host_probe() to register host
From: Rob Herring @ 2020-05-22 23:48 UTC (permalink / raw)
  To: Lorenzo Pieralisi
  Cc: Heiko Stuebner, linux-pci, Shawn Lin, linux-rockchip,
	Bjorn Helgaas, linux-arm-kernel
In-Reply-To: <20200522234832.954484-1-robh@kernel.org>

The rockchip host driver does the same host registration and bus scanning
calls as pci_host_probe, so let's use it instead.

Cc: Shawn Lin <shawn.lin@rock-chips.com>
Cc: Heiko Stuebner <heiko@sntech.de>
Cc: linux-rockchip@lists.infradead.org
Signed-off-by: Rob Herring <robh@kernel.org>
---
 drivers/pci/controller/pcie-rockchip-host.c | 18 ++++--------------
 drivers/pci/controller/pcie-rockchip.h      |  1 -
 2 files changed, 4 insertions(+), 15 deletions(-)

diff --git a/drivers/pci/controller/pcie-rockchip-host.c b/drivers/pci/controller/pcie-rockchip-host.c
index 94af6f5828a3..6a3c8442258b 100644
--- a/drivers/pci/controller/pcie-rockchip-host.c
+++ b/drivers/pci/controller/pcie-rockchip-host.c
@@ -949,7 +949,6 @@ static int rockchip_pcie_probe(struct platform_device *pdev)
 {
 	struct rockchip_pcie *rockchip;
 	struct device *dev = &pdev->dev;
-	struct pci_bus *bus, *child;
 	struct pci_host_bridge *bridge;
 	struct resource *bus_res;
 	int err;
@@ -1015,20 +1014,10 @@ static int rockchip_pcie_probe(struct platform_device *pdev)
 	bridge->map_irq = of_irq_parse_and_map_pci;
 	bridge->swizzle_irq = pci_common_swizzle;
 
-	err = pci_scan_root_bus_bridge(bridge);
+	err = pci_host_probe(bridge);
 	if (err < 0)
 		goto err_remove_irq_domain;
 
-	bus = bridge->bus;
-
-	rockchip->root_bus = bus;
-
-	pci_bus_size_bridges(bus);
-	pci_bus_assign_resources(bus);
-	list_for_each_entry(child, &bus->children, node)
-		pcie_bus_configure_settings(child);
-
-	pci_bus_add_devices(bus);
 	return 0;
 
 err_remove_irq_domain:
@@ -1051,9 +1040,10 @@ static int rockchip_pcie_remove(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	struct rockchip_pcie *rockchip = dev_get_drvdata(dev);
+	struct pci_host_bridge *bridge = pci_host_bridge_from_priv(rockchip);
 
-	pci_stop_root_bus(rockchip->root_bus);
-	pci_remove_root_bus(rockchip->root_bus);
+	pci_stop_root_bus(bridge->bus);
+	pci_remove_root_bus(bridge->bus);
 	irq_domain_remove(rockchip->irq_domain);
 
 	rockchip_pcie_deinit_phys(rockchip);
diff --git a/drivers/pci/controller/pcie-rockchip.h b/drivers/pci/controller/pcie-rockchip.h
index d90dfb354573..4012543bafbe 100644
--- a/drivers/pci/controller/pcie-rockchip.h
+++ b/drivers/pci/controller/pcie-rockchip.h
@@ -303,7 +303,6 @@ struct rockchip_pcie {
 	struct	device *dev;
 	struct	irq_domain *irq_domain;
 	int     offset;
-	struct pci_bus *root_bus;
 	void    __iomem *msg_region;
 	phys_addr_t msg_bus_addr;
 	bool is_rc;
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH 14/15] PCI: xilinx-nwl: Use pci_host_probe() to register host
From: Rob Herring @ 2020-05-22 23:48 UTC (permalink / raw)
  To: Lorenzo Pieralisi
  Cc: Bjorn Helgaas, linux-pci, Michal Simek, linux-arm-kernel
In-Reply-To: <20200522234832.954484-1-robh@kernel.org>

The xilinx-nwl host driver does the same host registration and bus scanning
calls as pci_host_probe, so let's use it instead.

The only difference is pci_assign_unassigned_bus_resources() was called
instead of pci_bus_size_bridges() and pci_bus_assign_resources(). This
should be the same.

Cc: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Rob Herring <robh@kernel.org>
---
 drivers/pci/controller/pcie-xilinx-nwl.c | 14 +-------------
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/drivers/pci/controller/pcie-xilinx-nwl.c b/drivers/pci/controller/pcie-xilinx-nwl.c
index 9bd1427f2fd6..32a0b08d6da5 100644
--- a/drivers/pci/controller/pcie-xilinx-nwl.c
+++ b/drivers/pci/controller/pcie-xilinx-nwl.c
@@ -817,8 +817,6 @@ static int nwl_pcie_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	struct nwl_pcie *pcie;
-	struct pci_bus *bus;
-	struct pci_bus *child;
 	struct pci_host_bridge *bridge;
 	int err;
 
@@ -871,17 +869,7 @@ static int nwl_pcie_probe(struct platform_device *pdev)
 		}
 	}
 
-	err = pci_scan_root_bus_bridge(bridge);
-	if (err)
-		return err;
-
-	bus = bridge->bus;
-
-	pci_assign_unassigned_bus_resources(bus);
-	list_for_each_entry(child, &bus->children, node)
-		pcie_bus_configure_settings(child);
-	pci_bus_add_devices(bus);
-	return 0;
+	return pci_host_probe(bridge);
 }
 
 static struct platform_driver nwl_pcie_driver = {
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH 10/15] PCI: altera: Use pci_host_probe() to register host
From: Rob Herring @ 2020-05-22 23:48 UTC (permalink / raw)
  To: Lorenzo Pieralisi
  Cc: Bjorn Helgaas, linux-pci, Ley Foon Tan, linux-arm-kernel, rfi
In-Reply-To: <20200522234832.954484-1-robh@kernel.org>

The altera host driver does the same host registration and bus scanning
calls as pci_host_probe, so let's use it instead.

The only difference is pci_assign_unassigned_bus_resources() was called
instead of pci_bus_size_bridges() and pci_bus_assign_resources(). This
should be the same.

Cc: Ley Foon Tan <ley.foon.tan@intel.com>
Cc: rfi@lists.rocketboards.org
Signed-off-by: Rob Herring <robh@kernel.org>
---
 drivers/pci/controller/pcie-altera.c | 17 +----------------
 1 file changed, 1 insertion(+), 16 deletions(-)

diff --git a/drivers/pci/controller/pcie-altera.c b/drivers/pci/controller/pcie-altera.c
index 24cb1c331058..26ac3ad81de0 100644
--- a/drivers/pci/controller/pcie-altera.c
+++ b/drivers/pci/controller/pcie-altera.c
@@ -773,8 +773,6 @@ static int altera_pcie_probe(struct platform_device *pdev)
 {
 	struct device *dev = &pdev->dev;
 	struct altera_pcie *pcie;
-	struct pci_bus *bus;
-	struct pci_bus *child;
 	struct pci_host_bridge *bridge;
 	int ret;
 	const struct of_device_id *match;
@@ -825,20 +823,7 @@ static int altera_pcie_probe(struct platform_device *pdev)
 	bridge->map_irq = of_irq_parse_and_map_pci;
 	bridge->swizzle_irq = pci_common_swizzle;
 
-	ret = pci_scan_root_bus_bridge(bridge);
-	if (ret < 0)
-		return ret;
-
-	bus = bridge->bus;
-
-	pci_assign_unassigned_bus_resources(bus);
-
-	/* Configure PCI Express setting. */
-	list_for_each_entry(child, &bus->children, node)
-		pcie_bus_configure_settings(child);
-
-	pci_bus_add_devices(bus);
-	return ret;
+	return pci_host_probe(bridge);
 }
 
 static int altera_pcie_remove(struct platform_device *pdev)
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH 09/15] PCI: xgene: Use pci_host_probe() to register host
From: Rob Herring @ 2020-05-22 23:48 UTC (permalink / raw)
  To: Lorenzo Pieralisi; +Cc: Bjorn Helgaas, linux-pci, Toan Le, linux-arm-kernel
In-Reply-To: <20200522234832.954484-1-robh@kernel.org>

The xgene host driver does the same host registration and bus scanning
calls as pci_host_probe, so let's use it instead.

Cc: Toan Le <toan@os.amperecomputing.com>
Signed-off-by: Rob Herring <robh@kernel.org>
---
 drivers/pci/controller/pci-xgene.c | 13 +------------
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/pci/controller/pci-xgene.c b/drivers/pci/controller/pci-xgene.c
index d1efa8ffbae1..5aee802946cb 100644
--- a/drivers/pci/controller/pci-xgene.c
+++ b/drivers/pci/controller/pci-xgene.c
@@ -591,7 +591,6 @@ static int xgene_pcie_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct device_node *dn = dev->of_node;
 	struct xgene_pcie_port *port;
-	struct pci_bus *bus, *child;
 	struct pci_host_bridge *bridge;
 	int ret;
 
@@ -632,17 +631,7 @@ static int xgene_pcie_probe(struct platform_device *pdev)
 	bridge->map_irq = of_irq_parse_and_map_pci;
 	bridge->swizzle_irq = pci_common_swizzle;
 
-	ret = pci_scan_root_bus_bridge(bridge);
-	if (ret < 0)
-		return ret;
-
-	bus = bridge->bus;
-
-	pci_assign_unassigned_bus_resources(bus);
-	list_for_each_entry(child, &bus->children, node)
-		pcie_bus_configure_settings(child);
-	pci_bus_add_devices(bus);
-	return 0;
+	return pci_host_probe(bridge);
 }
 
 static const struct of_device_id xgene_pcie_match_table[] = {
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH 12/15] PCI: rcar: Use pci_host_probe() to register host
From: Rob Herring @ 2020-05-22 23:48 UTC (permalink / raw)
  To: Lorenzo Pieralisi
  Cc: linux-pci, Yoshihiro Shimoda, linux-renesas-soc, Bjorn Helgaas,
	linux-arm-kernel, Marek Vasut
In-Reply-To: <20200522234832.954484-1-robh@kernel.org>

The rcar host driver does the same host registration and bus scanning
calls as pci_host_probe, so let's use it instead.

Cc: Marek Vasut <marek.vasut+renesas@gmail.com>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: linux-renesas-soc@vger.kernel.org
Signed-off-by: Rob Herring <robh@kernel.org>
---
 drivers/pci/controller/pcie-rcar-host.c | 18 +-----------------
 1 file changed, 1 insertion(+), 17 deletions(-)

diff --git a/drivers/pci/controller/pcie-rcar-host.c b/drivers/pci/controller/pcie-rcar-host.c
index d210a36561be..9069ad96fe95 100644
--- a/drivers/pci/controller/pcie-rcar-host.c
+++ b/drivers/pci/controller/pcie-rcar-host.c
@@ -330,8 +330,6 @@ static int rcar_pcie_enable(struct rcar_pcie_host *host)
 	struct pci_host_bridge *bridge = pci_host_bridge_from_priv(host);
 	struct rcar_pcie *pcie = &host->pcie;
 	struct device *dev = pcie->dev;
-	struct pci_bus *bus, *child;
-	int ret;
 
 	/* Try setting 5 GT/s link speed */
 	rcar_pcie_force_speedup(pcie);
@@ -349,21 +347,7 @@ static int rcar_pcie_enable(struct rcar_pcie_host *host)
 	if (IS_ENABLED(CONFIG_PCI_MSI))
 		bridge->msi = &host->msi.chip;
 
-	ret = pci_scan_root_bus_bridge(bridge);
-	if (ret < 0)
-		return ret;
-
-	bus = bridge->bus;
-
-	pci_bus_size_bridges(bus);
-	pci_bus_assign_resources(bus);
-
-	list_for_each_entry(child, &bus->children, node)
-		pcie_bus_configure_settings(child);
-
-	pci_bus_add_devices(bus);
-
-	return 0;
+	return pci_host_probe(bridge);
 }
 
 static int phy_wait_for_ack(struct rcar_pcie *pcie)
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH 11/15] PCI: iproc: Use pci_host_probe() to register host
From: Rob Herring @ 2020-05-22 23:48 UTC (permalink / raw)
  To: Lorenzo Pieralisi
  Cc: Scott Branden, linux-pci, bcm-kernel-feedback-list, Ray Jui,
	Bjorn Helgaas, linux-arm-kernel
In-Reply-To: <20200522234832.954484-1-robh@kernel.org>

The iproc host driver does the same host registration and bus scanning
calls as pci_host_probe, so let's use it instead.

The only difference is pci_assign_unassigned_bus_resources() was called
instead of pci_bus_size_bridges() and pci_bus_assign_resources(). This
should be the same.

Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Ray Jui <rjui@broadcom.com>
Cc: Scott Branden <sbranden@broadcom.com>
Cc: bcm-kernel-feedback-list@broadcom.com
Signed-off-by: Rob Herring <robh@kernel.org>
---
 drivers/pci/controller/pcie-iproc.c | 18 +++++-------------
 drivers/pci/controller/pcie-iproc.h |  2 --
 2 files changed, 5 insertions(+), 15 deletions(-)

diff --git a/drivers/pci/controller/pcie-iproc.c b/drivers/pci/controller/pcie-iproc.c
index 8c7f875acf7f..232fca0754e1 100644
--- a/drivers/pci/controller/pcie-iproc.c
+++ b/drivers/pci/controller/pcie-iproc.c
@@ -1470,7 +1470,6 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct list_head *res)
 {
 	struct device *dev;
 	int ret;
-	struct pci_bus *child;
 	struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
 
 	dev = pcie->dev;
@@ -1531,21 +1530,12 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct list_head *res)
 	host->map_irq = pcie->map_irq;
 	host->swizzle_irq = pci_common_swizzle;
 
-	ret = pci_scan_root_bus_bridge(host);
+	ret = pci_host_probe(host);
 	if (ret < 0) {
 		dev_err(dev, "failed to scan host: %d\n", ret);
 		goto err_power_off_phy;
 	}
 
-	pci_assign_unassigned_bus_resources(host->bus);
-
-	pcie->root_bus = host->bus;
-
-	list_for_each_entry(child, &host->bus->children, node)
-		pcie_bus_configure_settings(child);
-
-	pci_bus_add_devices(host->bus);
-
 	return 0;
 
 err_power_off_phy:
@@ -1558,8 +1548,10 @@ EXPORT_SYMBOL(iproc_pcie_setup);
 
 int iproc_pcie_remove(struct iproc_pcie *pcie)
 {
-	pci_stop_root_bus(pcie->root_bus);
-	pci_remove_root_bus(pcie->root_bus);
+	struct pci_host_bridge *host = pci_host_bridge_from_priv(pcie);
+
+	pci_stop_root_bus(host->bus);
+	pci_remove_root_bus(host->bus);
 
 	iproc_pcie_msi_disable(pcie);
 
diff --git a/drivers/pci/controller/pcie-iproc.h b/drivers/pci/controller/pcie-iproc.h
index 4f03ea539805..c2676e442f55 100644
--- a/drivers/pci/controller/pcie-iproc.h
+++ b/drivers/pci/controller/pcie-iproc.h
@@ -54,7 +54,6 @@ struct iproc_msi;
  * @reg_offsets: register offsets
  * @base: PCIe host controller I/O register base
  * @base_addr: PCIe host controller register base physical address
- * @root_bus: pointer to root bus
  * @phy: optional PHY device that controls the Serdes
  * @map_irq: function callback to map interrupts
  * @ep_is_internal: indicates an internal emulated endpoint device is connected
@@ -85,7 +84,6 @@ struct iproc_pcie {
 	void __iomem *base;
 	phys_addr_t base_addr;
 	struct resource mem;
-	struct pci_bus *root_bus;
 	struct phy *phy;
 	int (*map_irq)(const struct pci_dev *, u8, u8);
 	bool ep_is_internal;
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH 08/15] PCI: versatile: Use pci_host_probe() to register host
From: Rob Herring @ 2020-05-22 23:48 UTC (permalink / raw)
  To: Lorenzo Pieralisi; +Cc: Bjorn Helgaas, linux-pci, linux-arm-kernel
In-Reply-To: <20200522234832.954484-1-robh@kernel.org>

The versatile host driver does the same host registration and bus scanning
calls as pci_host_probe, so let's use it instead.

Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Rob Herring <robh@kernel.org>
---
 drivers/pci/controller/pci-versatile.c | 14 +-------------
 1 file changed, 1 insertion(+), 13 deletions(-)

diff --git a/drivers/pci/controller/pci-versatile.c b/drivers/pci/controller/pci-versatile.c
index b911359b6d81..e90f0cc65c73 100644
--- a/drivers/pci/controller/pci-versatile.c
+++ b/drivers/pci/controller/pci-versatile.c
@@ -70,7 +70,6 @@ static int versatile_pci_probe(struct platform_device *pdev)
 	int ret, i, myslot = -1, mem = 1;
 	u32 val;
 	void __iomem *local_pci_cfg_base;
-	struct pci_bus *bus, *child;
 	struct pci_host_bridge *bridge;
 
 	bridge = devm_pci_alloc_host_bridge(dev, 0);
@@ -164,18 +163,7 @@ static int versatile_pci_probe(struct platform_device *pdev)
 	bridge->map_irq = of_irq_parse_and_map_pci;
 	bridge->swizzle_irq = pci_common_swizzle;
 
-	ret = pci_scan_root_bus_bridge(bridge);
-	if (ret < 0)
-		return ret;
-
-	bus = bridge->bus;
-
-	pci_assign_unassigned_bus_resources(bus);
-	list_for_each_entry(child, &bus->children, node)
-		pcie_bus_configure_settings(child);
-	pci_bus_add_devices(bus);
-
-	return 0;
+	return pci_host_probe(bridge);
 }
 
 static const struct of_device_id versatile_pci_of_match[] = {
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH 07/15] PCI: v3: Use pci_host_probe() to register host
From: Rob Herring @ 2020-05-22 23:48 UTC (permalink / raw)
  To: Lorenzo Pieralisi
  Cc: Bjorn Helgaas, linux-pci, Linus Walleij, linux-arm-kernel
In-Reply-To: <20200522234832.954484-1-robh@kernel.org>

The v3 host driver does the same host registration and bus scanning
calls as pci_host_probe, so let's use it instead.

Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Rob Herring <robh@kernel.org>
---
 drivers/pci/controller/pci-v3-semi.c | 13 +------------
 1 file changed, 1 insertion(+), 12 deletions(-)

diff --git a/drivers/pci/controller/pci-v3-semi.c b/drivers/pci/controller/pci-v3-semi.c
index 3681e5af3878..198cf2c6ed92 100644
--- a/drivers/pci/controller/pci-v3-semi.c
+++ b/drivers/pci/controller/pci-v3-semi.c
@@ -239,7 +239,6 @@ struct v3_pci {
 	struct device *dev;
 	void __iomem *base;
 	void __iomem *config_base;
-	struct pci_bus *bus;
 	u32 config_mem;
 	u32 non_pre_mem;
 	u32 pre_mem;
@@ -904,17 +903,7 @@ static int v3_pci_probe(struct platform_device *pdev)
 	val |= V3_SYSTEM_M_LOCK;
 	writew(val, v3->base + V3_SYSTEM);
 
-	ret = pci_scan_root_bus_bridge(host);
-	if (ret) {
-		dev_err(dev, "failed to register host: %d\n", ret);
-		return ret;
-	}
-	v3->bus = host->bus;
-
-	pci_bus_assign_resources(v3->bus);
-	pci_bus_add_devices(v3->bus);
-
-	return 0;
+	return pci_host_probe(host);
 }
 
 static const struct of_device_id v3_pci_of_match[] = {
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related

* [PATCH 05/15] PCI: mobiveil: Use pci_host_probe() to register host
From: Rob Herring @ 2020-05-22 23:48 UTC (permalink / raw)
  To: Lorenzo Pieralisi
  Cc: Bjorn Helgaas, linux-pci, Hou Zhiqiang, Karthikeyan Mitran,
	linux-arm-kernel
In-Reply-To: <20200522234832.954484-1-robh@kernel.org>

The mobiveil host driver does the same host registration and bus scanning
calls as pci_host_probe, so let's use it instead.

Cc: Karthikeyan Mitran <m.karthikeyan@mobiveil.co.in>
Cc: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
Signed-off-by: Rob Herring <robh@kernel.org>
---
 .../pci/controller/mobiveil/pcie-mobiveil-host.c | 16 +---------------
 1 file changed, 1 insertion(+), 15 deletions(-)

diff --git a/drivers/pci/controller/mobiveil/pcie-mobiveil-host.c b/drivers/pci/controller/mobiveil/pcie-mobiveil-host.c
index 5907baa9b1f2..5974619811ec 100644
--- a/drivers/pci/controller/mobiveil/pcie-mobiveil-host.c
+++ b/drivers/pci/controller/mobiveil/pcie-mobiveil-host.c
@@ -569,8 +569,6 @@ int mobiveil_pcie_host_probe(struct mobiveil_pcie *pcie)
 	struct mobiveil_root_port *rp = &pcie->rp;
 	struct pci_host_bridge *bridge = rp->bridge;
 	struct device *dev = &pcie->pdev->dev;
-	struct pci_bus *bus;
-	struct pci_bus *child;
 	int ret;
 
 	ret = mobiveil_pcie_parse_dt(pcie);
@@ -620,17 +618,5 @@ int mobiveil_pcie_host_probe(struct mobiveil_pcie *pcie)
 		return ret;
 	}
 
-	/* setup the kernel resources for the newly added PCIe root bus */
-	ret = pci_scan_root_bus_bridge(bridge);
-	if (ret)
-		return ret;
-
-	bus = bridge->bus;
-
-	pci_assign_unassigned_bus_resources(bus);
-	list_for_each_entry(child, &bus->children, node)
-		pcie_bus_configure_settings(child);
-	pci_bus_add_devices(bus);
-
-	return 0;
+	return pci_host_probe(bridge);
 }
-- 
2.25.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox