In the snippets like the following
if (...)
return / goto / break / continue ...;
else
...
the 'else' is redundant. Get rid of it.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 58 ++--
1 file
On Wed, Oct 18, 2023 at 03:52:36PM +0300, Andy Shevchenko wrote:
> On Wed, Oct 18, 2023 at 11:09:35AM +0200, Hans de Goede wrote:
> > On 10/18/23 07:10, Andy Shevchenko wrote:
...
> > Yes I should be able to find a device or 2 which poke GPIOs from the
> > VBT MIPI seque
Taking all this into consideration replace the hack
with proper GPIO APIs being used.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 47 +---
1 file changed, 10 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
b/drive
Names of the MIPI sequence steps are sequential and defined, no
need to check for the gaps. However in seq_name the MIPI_SEQ_END
is missing. Add it there, and drop unneeded NULL check in
sequence_name().
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 3 ++-
1
Drop unused vlv_iosf_sb_read() and vlv_iosf_sb_write().
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/vlv_sideband.c | 17 -
drivers/gpu/drm/i915/vlv_sideband.h | 3 ---
2 files changed, 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/vlv_sideband.c
b/drivers/gpu
Extract a common soc_gpio_exec() helper that may be used by a few SoCs.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 49 +++-
1 file changed, 27 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
b
Move existing condition to while(), so it will be clear on what
circumstances the loop is successfully finishing.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display
On Wed, Oct 18, 2023 at 11:09:35AM +0200, Hans de Goede wrote:
> On 10/18/23 07:10, Andy Shevchenko wrote:
> > DSI code for VBT has a set of ugly GPIO hacks, one of which is direct
> > talking to GPIO IP behind the actual driver's back. An attempt to fix
> > that is here.
>
that use this piece of code,
is it possible to give a test run on (one of) them?
Andy Shevchenko (2):
drm/i915/dsi: Extract common soc_gpio_exec() helper
drm/i915/dsi: Replace poking of VLV GPIOs behind the driver's back
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 150 +++
1 file
Taking all this into consideration replace the hack with proper
GPIO APIs being used.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 101 ++-
1 file changed, 31 insertions(+), 70 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
b/drivers/gp
Extract a common soc_gpio_exec() helper that may be used by a few SoCs.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 49 +++-
1 file changed, 27 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
b
Our library has memparse() for parsing numbers with respective suffixes
suitable for memory sizes. Use it instead of custom implementation.
Signed-off-by: Andy Shevchenko
---
drivers/video/fbdev/omap/omapfb_main.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git
There is no point in shadowing the error codes from platform_get_irq().
Refactor omapfb_do_probe() accordingly.
Signed-off-by: Andy Shevchenko
---
drivers/video/fbdev/omap/omapfb_main.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/video/fbdev/omap
; cares.
ENOMEM is good for the real allocation calls, here is not the one (the one is
below). Hence ENOMEM is not good candidate above. And whenever functions returns
an error pointer the caller must not assume that it will be only ENOMEM for
allocators.
> > + return memdup_user(src, nbytes);
> > +}
--
With Best Regards,
Andy Shevchenko
n * size to calculate array sizes.
No objections,
Reviewed-by: Andy Shevchenko
--
With Best Regards,
Andy Shevchenko
change that I think can happen
sooner than later.
--
With Best Regards,
Andy Shevchenko
for function redefinition, if that is the case I would like to
> drop this patch.
>
> static inline struct drm_bridge *devm_drm_of_get_bridge()
>
> vs
>
> struct drm_bridge *devm_drm_of_get_bridge()
Yeah, yet another argument in favour of switching to fwnode.
--
With Best Regards,
Andy Shevchenko
On Thu, Aug 31, 2023 at 4:16 PM Andy Shevchenko
wrote:
> On Thu, Aug 31, 2023 at 3:22 PM Philipp Stanner wrote:
> > On Wed, 2023-08-30 at 17:11 +0300, Andy Shevchenko wrote:
> > > On Wed, Aug 30, 2023 at 4:46 PM Philipp Stanner
> > > wrote:
...
> > > I'm w
On Thu, Aug 31, 2023 at 3:22 PM Philipp Stanner wrote:
> On Wed, 2023-08-30 at 17:11 +0300, Andy Shevchenko wrote:
> > On Wed, Aug 30, 2023 at 4:46 PM Philipp Stanner
> > wrote:
...
> > I'm wondering if this has no side-effects as string.h/string.c IIRC
> > is used
On Wed, Aug 30, 2023 at 10:15 PM wrote:
> On Wed, 2023-08-30 at 17:29 +0300, Andy Shevchenko wrote:
> > On Wed, Aug 30, 2023 at 5:19 PM wrote:
> > > On Wed, 2023-08-30 at 17:11 +0300, Andy Shevchenko wrote:
> > > > On Wed, Aug 30, 2023 at 4:46 PM Philipp
On Wed, Aug 30, 2023 at 5:19 PM wrote:
> On Wed, 2023-08-30 at 17:11 +0300, Andy Shevchenko wrote:
> > On Wed, Aug 30, 2023 at 4:46 PM Philipp Stanner
> > wrote:
> > > --- a/include/linux/string.h
> > > +++ b/include/linux/string.h
> >
> > I'm wond
-
With Best Regards,
Andy Shevchenko
by kfree().
> + */
...
> +/**
> + * vmemdup_array_user - duplicate array from user space
> + *
Redundant?
> + * @src: source address in user space
> + * @n: number of array members to copy
> + * @size: size of one array member
> + *
> + * Return: an ERR_PTR() on failure. Result may be not
> + * physically contiguous. Use kvfree() to free.
> + */
--
With Best Regards,
Andy Shevchenko
On Mon, Aug 28, 2023 at 02:29:21PM +0300, Laurent Pinchart wrote:
> On Mon, Aug 28, 2023 at 02:17:02PM +0300, Andy Shevchenko wrote:
> > On Sat, Aug 26, 2023 at 08:19:01AM +0100, Biju Das wrote:
> > > Having conditional around the of_node pointers turns out to make driver
&
it
> from the driver as it saves some memory.
Reviewed-by: Andy Shevchenko
--
With Best Regards,
Andy Shevchenko
t; struct device_node *of_node;
> -#endif
This simply has to be struct fwnode_handle to begin with.
Can you convert the driver to use it?
--
With Best Regards,
Andy Shevchenko
t from
being instantiated on ACPI based systems (even if there is no ACPI ID
table, due to a gateway called PRP0001).
> to Kconfig, and drop the
>
> #if IS_ENABLED(CONFIG_OF)
>
> from the driver ?
Contrary this is an idea I fully support!
--
With Best Regards,
Andy Shevchenko
On Wed, Aug 23, 2023 at 9:39 PM Doug Anderson wrote:
> On Wed, Aug 23, 2023 at 10:10 AM Andy Shevchenko
> wrote:
> >
> > > No. Please, do not remove the I2C ID table. It had already been
> > > discussed a few years ago.
> > >
> > > > Yes,
On Wed, Aug 23, 2023 at 8:14 PM Doug Anderson wrote:
> On Wed, Aug 23, 2023 at 9:53 AM Andy Shevchenko
> wrote:
> > On Wed, Aug 23, 2023 at 5:36 PM Biju Das wrote:
...
> > No. Please, do not remove the I2C ID table. It had already been
> > discussed a few years ago
On Wed, Aug 23, 2023 at 7:52 PM Andy Shevchenko
wrote:
> On Wed, Aug 23, 2023 at 5:36 PM Biju Das wrote:
> > > On Sun, Aug 13, 2023 at 1:51 AM Biju Das
> > > wrote:
...
> > > It seems like this is a sign that nobody is actually using the i2c match
> > >
hen someone has an actual need then they can
> > re-add it.
> >
> > Sound OK?
No. Please, do not remove the I2C ID table. It had already been
discussed a few years ago.
> Yes, it make sense, as it saves some memory.
--
With Best Regards,
Andy Shevchenko
On Fri, Aug 18, 2023 at 05:54:50PM +0100, Biju Das wrote:
> This patch series aims to add match data improvements for it66121 driver.
With the Fixes removed, FWIW,
Reviewed-by: Andy Shevchenko
--
With Best Regards,
Andy Shevchenko
th these compatible and i2c IDs.
--
With Best Regards,
Andy Shevchenko
> module.
...
> drivers/pwm/pwm-lpss.c | 1 -
Acked-by: Andy Shevchenko # Intel LPSS
--
With Best Regards,
Andy Shevchenko
On Thu, Aug 03, 2023 at 10:24:46AM -0700, Andrew Morton wrote:
> On Thu, 3 Aug 2023 16:19:18 +0300 Andy Shevchenko
> wrote:
...
> > +#define abs_diff(a, b) ({ \
> > + typeof(a) __a = (a);\
> > + typeof(b) __b = (b);
abs_diff() belongs to math.h. Move it there.
This will allow others to use it.
Reviewed-by: Jiri Slaby # tty/serial
Acked-by: Jani Nikula
Acked-by: Greg Kroah-Hartman
Reviewed-by: Andi Shyti
Reviewed-by: Philipp Zabel # gpu/ipu-v3
Signed-off-by: Andy Shevchenko
---
v4:
- Cc'ed to Andrew
he of_match_ptr(), since the only thing it can
> possibly do is to save a few bytes of .text if a driver can be used both
> with and without it.
>
> Signed-off-by: Zhu Wang
> Reviewed-by: Arnd Bergmann
> Reviewed-by: Andy Shevchenko
I haven't given you any tag, why is this line he
but not
for the rest).
--
With Best Regards,
Andy Shevchenko
sage.
Do we have firmware node of PWM available? I would print it rather than some
(possibly non-unique) string.
--
With Best Regards,
Andy Shevchenko
abs_diff() belongs to math.h. Move it there.
This will allow others to use it.
Signed-off-by: Andy Shevchenko
Reviewed-by: Jiri Slaby # tty/serial
---
v3: added tag (Jiri), removed space after a cast (fdo CI)
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 1 +
drivers/gpu/drm/i915/display
abs_diff() belongs to math.h. Move it there.
This will allow others to use it.
Signed-off-by: Andy Shevchenko
---
v2: better header location on ipu-v3, converted omap-serial as well
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 1 +
drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 7
On Fri, Jul 21, 2023 at 04:42:35PM +0300, Andy Shevchenko wrote:
> abs_diff() belongs to math.h. Move it there.
> This will allow others to use it.
Sorry, forgot omap-serial case.
Will be v2 soon.
--
With Best Regards,
Andy Shevchenko
abs_diff() belongs to math.h. Move it there.
This will allow others to use it.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 1 +
drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 7 ---
drivers/gpu/ipu-v3/ipu-image-convert.c| 14
the initial power state.
>
> Fixes: 706dc68102bc ("backlight: gpio: Explicitly set the direction of the
> GPIO")
> Signed-off-by: Liu Ying
--
With Best Regards,
Andy Shevchenko
ot;).
>
> Quote:
> ---
> If in DT boot we have phandle link then leave the GPIO in a state which the
> bootloader left it and let the user of the backlight to configure it further.
> ---
>
> So, let's drop output gpio direction check and only check gpio value to set
> the initial power state.
> -8<---
--
With Best Regards,
Andy Shevchenko
ion. There is no
prohibition on reading value for the pin that is in any direction.
I.o.w. if the direction here is a problem it should have been
configured beforehand.
--
With Best Regards,
Andy Shevchenko
On Tue, Jul 04, 2023 at 10:20:35AM +0300, Andy Shevchenko wrote:
> On Tue, Jul 04, 2023 at 01:05:28AM +0200, Javier Martinez Canillas wrote:
...
> Wondering if
>
> if FB_CORE
> ...
> endif
>
> makes Kconfig looking better instead of replacing all these "d
e"
> - depends on FB
> + depends on FB_CORE
> default y
--
With Best Regards,
Andy Shevchenko
deo/fbdev/core/Kconfig"
Hmm... Shan't we start Kconfig from core options?
--
With Best Regards,
Andy Shevchenko
On Fri, Jun 30, 2023 at 10:29:20PM +0200, Javier Martinez Canillas wrote:
> Andy Shevchenko writes:
> > On Fri, Jun 30, 2023 at 07:38:01PM +0200, Javier Martinez Canillas wrote:
> >> Andy Shevchenko writes:
> >> > On Fri, Jun 30, 2023 at 12:51:02AM +0200,
On Fri, Jun 30, 2023 at 08:42:21PM +0300, Andy Shevchenko wrote:
> On Fri, Jun 30, 2023 at 07:38:01PM +0200, Javier Martinez Canillas wrote:
> > Andy Shevchenko writes:
> > > On Fri, Jun 30, 2023 at 12:51:02AM +0200, Javier Martinez Canillas wrote:
...
> >
On Fri, Jun 30, 2023 at 07:38:01PM +0200, Javier Martinez Canillas wrote:
> Andy Shevchenko writes:
> > On Fri, Jun 30, 2023 at 12:51:02AM +0200, Javier Martinez Canillas wrote:
> >> This patch series splits the fbdev core support in two different Kconfig
> >&
B_CORE,
> CONFIG_DRM_FBDEV_EMULATION and CONFIG_FB_DEVICE symbols set to 'y' or 'n'.
>
> Patch 1/2 makes the CONFIG_FB split that is mentioned above and patch 2/2
> makes DRM fbdev emulation depend on the new FB_CORE symbol instead of FB.
--
With Best Regards,
Andy Shevchenko
On Tue, Jun 20, 2023 at 10:25:21AM -0700, Lucas De Marchi wrote:
> On Tue, Jun 20, 2023 at 05:55:19PM +0300, Andy Shevchenko wrote:
> > On Tue, Jun 20, 2023 at 05:47:34PM +0300, Jani Nikula wrote:
> > > On Thu, 15 Jun 2023, Andy Shevchenko
> > > wrote:
> > >
On Tue, Jun 20, 2023 at 05:47:34PM +0300, Jani Nikula wrote:
> On Thu, 15 Jun 2023, Andy Shevchenko
> wrote:
> > On Fri, May 12, 2023 at 02:45:19PM +0300, Jani Nikula wrote:
> >> On Fri, 12 May 2023, Andy Shevchenko
> >> wrote:
> >> > On Fri, May 12, 2
On Fri, May 12, 2023 at 09:29:23AM -0700, Lucas De Marchi wrote:
> On Fri, May 12, 2023 at 02:14:19PM +0300, Andy Shevchenko wrote:
> > On Mon, May 08, 2023 at 10:14:02PM -0700, Lucas De Marchi wrote:
> > > Add GENMASK_U32(), GENMASK_U16() and GENMASK_U8() macros to create
>
On Fri, May 12, 2023 at 02:45:19PM +0300, Jani Nikula wrote:
> On Fri, 12 May 2023, Andy Shevchenko
> wrote:
> > On Fri, May 12, 2023 at 02:25:18PM +0300, Jani Nikula wrote:
> >> On Fri, 12 May 2023, Andy Shevchenko
> >> wrote:
> >> > On Mon, May 08,
On Mon, Mar 20, 2023 at 01:54:26PM +0200, Andy Shevchenko wrote:
> On Fri, Mar 17, 2023 at 09:53:40PM +0100, Linus Walleij wrote:
> > On Fri, Mar 17, 2023 at 7:51 PM Andy Shevchenko
> > wrote:
> >
> > > The of_gpio.h is going to be removed. In preparation of
On Fri, May 12, 2023 at 02:25:18PM +0300, Jani Nikula wrote:
> On Fri, 12 May 2023, Andy Shevchenko
> wrote:
> > On Mon, May 08, 2023 at 10:14:02PM -0700, Lucas De Marchi wrote:
> >> Add GENMASK_U32(), GENMASK_U16() and GENMASK_U8() macros to create
> >> masks
_Generic() in case you still wish to implement this.
--
With Best Regards,
Andy Shevchenko
for retu IRQ */
> + GPIO_LOOKUP("gpio-48-63", 15, "retu_irq",
> + GPIO_ACTIVE_HIGH),
> + /* GPIO used for tahvo IRQ */
> + GPIO_LOOKUP("gpio-32-47", 8, "tahvo_irq",
> + GPIO_ACTIVE_HIGH),
Missing terminator.
> + },
> +};
--
With Best Regards,
Andy Shevchenko
{
> + .dev_id = "spi0.0",
> + .table = {
> + GPIO_LOOKUP("alchemy-gpio2", 21,
> + "pendown", GPIO_ACTIVE_HIGH),
> + { },
Ditto.
> + },
> +};
--
With Best Regards,
Andy Shevchenko
subsystem has a lot of
such cases.
> > + help
> > + DRM display helpers for USB Type-C Displayport Alternate mode.
--
With Best Regards,
Andy Shevchenko
On Wed, Mar 22, 2023 at 06:27:56PM +0200, Jani Nikula wrote:
> On Wed, 22 Mar 2023, Andy Shevchenko
> wrote:
> > On Wed, Mar 22, 2023 at 06:46:32PM +0800, Pin-yen Lin wrote:
> >> +#ifdef CONFIG_DRM_DISPLAY_DP_TYPEC_HELPER
> >
> > Ah, maybe this should use IS
>extcon = extcon;
...
> + ret = it6505_register_typec_switches(dev, it6505);
> + if (ret != -ENODEV)
> + dev_warn(dev, "Didn't register Type-C switches, err: %d\n",
> ret);
> +
Unnecessary blank line.
> + if (ret && !it6505->extcon) {
> + dev_err(dev, "Both extcon and Type-C switch are not
> registered.\n");
> + return -EINVAL;
Why not return ret here?
> + }
--
With Best Regards,
Andy Shevchenko
eof(*ctx->port_data),
?
> + GFP_KERNEL);
> + if (!ctx->port_data) {
> + ret = -ENOMEM;
> + goto unregister_mux;
> + }
...
> +struct anx7625_typec_port_data {
> + bool dp_connected;
> + enum typec_orientation orientation;
Most likely enum will be 32-bit and bool 8-bit. Which means that the data type
size become 8 bytes for no reason. Can you swap the lines and perhaps check this
with `pahole` tool?
> +};
--
With Best Regards,
Andy Shevchenko
it depends on if there will be no new users for those DRM
> helpers while waiting the new APIs being merged in DRM tree. More users we
> see in DRM, more effort the clean-up requires.
>
> I have no strong opinion on this specific case. I'd just be happy to see the
> IIO tests getting in preferably sooner than later - although 'soon' and
> 'late' does also depend on other factors besides these helpers...
Since I'm not a maintainer of either, and one of them requires something,
I can't oppose.
--
With Best Regards,
Andy Shevchenko
+void *data, typec_mux_set_fn_t mux_set);
> +#else
> +static inline void drm_dp_unregister_typec_switches(struct
> drm_dp_typec_switch_desc *switch_desc)
> +{
> +}
> +static inline int drm_dp_register_typec_switches(
> + struct device *dev, struct fwnode_handle *port,
> + struct drm_dp_typec_switch_desc *switch_desc, void *data,
> + typec_mux_set_fn_t mux_set)
> +{
> + return -EOPNOTSUPP;
> +}
> +#endif
--
With Best Regards,
Andy Shevchenko
ux for the bu27034 with RAW IIO_LIGHT channel and scale
> - Fix bug from added in v4 bu27034 time setting.
--
With Best Regards,
Andy Shevchenko
Today and in any
> case during this week. I'll be CC:ing you and Brendan with (relevant
> patches of) v5 as well.
Thank you, folks, for doing this. Let's make Linux kernel greater
(than it is already is).
--
With Best Regards,
Andy Shevchenko
On Fri, Mar 17, 2023 at 09:53:40PM +0100, Linus Walleij wrote:
> On Fri, Mar 17, 2023 at 7:51 PM Andy Shevchenko
> wrote:
>
> > The of_gpio.h is going to be removed. In preparation of that convert
> > the driver to the agnostic API.
> >
> > Signed-off-by: Andy S
The of_gpio.h is going to be removed. In preparation of that convert
the driver to the agnostic API.
Signed-off-by: Andy Shevchenko
---
drivers/gpio/gpiolib-of.c| 4 +-
drivers/video/backlight/hx8357.c | 74 ++--
2 files changed, 24 insertions(+), 54
On Wed, Mar 08, 2023 at 09:51:19PM +0800, Pin-yen Lin wrote:
> On Mon, Mar 6, 2023 at 8:03 PM Andy Shevchenko
> wrote:
> > On Fri, Mar 03, 2023 at 10:33:50PM +0800, Pin-yen Lin wrote:
...
> > > + it6505->port_data[i].lane_swap = (dp_lanes[0] / 2 =
On Wed, Mar 08, 2023 at 06:20:14PM +0800, Pin-yen Lin wrote:
> On Mon, Mar 6, 2023 at 7:49 PM Andy Shevchenko
> > On Fri, Mar 03, 2023 at 10:33:43PM +0800, Pin-yen Lin wrote:
...
> > > + switch_desc->typec_ports = devm_kcalloc(dev,
> > > s
on the kernel
>commandline.
...
> + depends on ACPI_VIDEO=n || ACPI_VIDEO
I'm wondering if "imply ACPI_VIDEO" (i.o.w. weak dependency) is what suitable
here.
--
With Best Regards,
Andy Shevchenko
+ return -EINVAL;
> + }
> + }
Perhaps
if (ret != -ENODEV)
dev_warn(dev, "Didn't register Type-C switches, err: %d\n",
ret);
if (ret && !it6505->extcon) {
dev_err(dev, "Both extcon and typec-switch are not
registered.\n");
return ret;
}
?
--
With Best Regards,
Andy Shevchenko
o unregister_mux;
> + }
...
> + ctx->port_data[i].orientation = (dp_lanes[0] / 2 == 0) ?
> + TYPEC_ORIENTATION_REVERSE : TYPEC_ORIENTATION_NORMAL;
I believe that this is an error prone check, you should rather do the opposite,
i.e. ' % 2 == 0'.
--
With Best Regards,
Andy Shevchenko
d to drop reference count here?
(I don't know myself, so, please check this)
If no, patch LGTM.
> + if (count)
> + return 0;
--
With Best Regards,
Andy Shevchenko
ch_desc->num_typec_switches,
> + sizeof(struct
> drm_dp_typec_port_data),
> + GFP_KERNEL);
> + if (!switch_desc->typec_ports)
> + return -ENOMEM;
How often this function _can_ be called during the runtime?
If it's _possible_ to call it infinite times, consider *not* using devm.
--
With Best Regards,
Andy Shevchenko
cher code to evaluate those for a match too, instead
> of only looking at the remote parent devices. This is required when a
> device supports two mode switches in its endpoints, so we can't simply
> register the mode switch with the parent node.
OK!
Reviewed-by: Andy Shevchenko
> Signed-
On Wed, Feb 22, 2023 at 04:53:41PM +0800, Pin-yen Lin wrote:
> On Tue, Feb 21, 2023 at 7:48 PM Andy Shevchenko
> > On Tue, Feb 21, 2023 at 05:50:47PM +0800, Pin-yen Lin wrote:
...
> > > #include
> > > #include
> > > +#include
> >
> >
dev_err(dev,
> + "Error on getting data lanes count from %pfwP:
> %d\n",
> + fwnode, num_lanes);
> + ret = num_lanes;
> + goto unregister_mux;
> + }
Same two comments as per previous patch of similar semantics.
--
With Best Regards,
Andy Shevchenko
> + fwnode_handle_put(fwnode);
> + return 0;
> + }
With the proposed count API:
unsigned int count;
...
port_node = ...
count = typec_mode_switch_node_count(_node->fwnode);
if (count == 0)
return 0;
--
With Best Regards,
Andy Shevchenko
or_each_if(fwnode_property_present((sw), "mode-switch"))
Please don't use fwnode namespace (see above), something like
#define for_each_typec_mode_switch_node(port, sw) \
...
--
With Best Regards,
Andy Shevchenko
On Tue, Feb 21, 2023 at 05:50:50PM +0800, Pin-yen Lin wrote:
> These two drivers embed a i2c_client in there private driver data, but
> only strict device is actually needed. Replace the i2c_client reference
> with a struct device one.
LGTM,
Reviewed-by: Andy Shevchenko
> Signed-off
EC_ORIENTATION_NORMAL;
> + ctx->port_data[i].dp_connected = false;
> + }
> + complete_all(>mux_register);
> +
> + return 0;
> +
> +unregister_mux:
> + complete_all(>mux_register);
> + anx7625_unregister_typec_switches(ctx);
> + return ret;
> +}
--
With Best Regards,
Andy Shevchenko
ray.
> * If @matches is NULL @matches_len is ignored and the total number of
> resolved
> * matches is returned.
Ditto.
--
With Best Regards,
Andy Shevchenko
-C
> connector, which ends up updating the lane swap registers of the it6505
> chip.
Same / similar comments as per previous patch.
--
With Best Regards,
Andy Shevchenko
; 2) {
> + dev_err(dev,
> + "Error on getting data lanes count from %pfwP:
> %d\n",
> + fwnode, num_lanes);
> + ret = num_lanes;
ret == 0?! Carefully consider all cases.
> + goto unregister_mux;
> + }
--
With Best Regards,
Andy Shevchenko
of_node_put(sw);
> + return 0;
> + }
> + }
--
With Best Regards,
Andy Shevchenko
't checked the rest
of the patches, though), perhaps
#define fwnode_for_each_typec_mode_switch(port, sw) \
fwnode_for_each_child_node(port, sw)\
if (!fwnode_property_present(sw, "mode-switch")) {} else
?
--
With Best Regards,
Andy Shevchenko
arry the fix as necessary. This is now fixed as far as linux-next
> is concerned, but any non trivial conflicts should be mentioned to your
> upstream maintainer when your tree is submitted for merging. You may
> also want to consider cooperating with the maintainer of the conflicting
> tree to minimise any particularly complex conflicts.
--
With Best Regards,
Andy Shevchenko
On Fri, Jan 20, 2023 at 03:06:02PM -0800, John Harrison wrote:
> On 1/19/2023 07:16, Andy Shevchenko wrote:
> > On Wed, Jan 18, 2023 at 10:49:55PM -0800, john.c.harri...@intel.com wrote:
...
> > > + found = false;
> > > +
ssed up with the guc_state itself, I think
you don't need to perform the above check under spinlock, so it's safe.
> + if (found) {
> intel_engine_set_hung_context(engine, ce);
--
With Best Regards,
Andy Shevchenko
On Wed, Jan 18, 2023 at 09:34:47AM -0800, John Harrison wrote:
> On 1/18/2023 00:29, Andy Shevchenko wrote:
> > On Tue, Jan 17, 2023 at 01:36:26PM -0800, john.c.harri...@intel.com wrote:
> > > From: John Harrison
> > >
> > > When GuC support was added
odrigo Vivi
> Cc: Tvrtko Ursulin
> Cc: Daniele Ceraolo Spurio
> Cc: Andrzej Hajda
> Cc: Chris Wilson
> Cc: Matthew Auld
> Cc: Matt Roper
> Cc: Umesh Nerlige Ramappa
> Cc: Michael Cheng
> Cc: Lucas De Marchi
> Cc: Tejas Upadhyay
> Cc: Andy Shevchenko
&
tinue-ing here,
> and fwnode_handle_put(node) is called latter in the loop [1][2]
>
> BR,
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/base/property.c#n1256
> [2]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/base/property.c#n1261
I'm really puzzled what do you mean by all this.
Sakari is right, btw.
--
With Best Regards,
Andy Shevchenko
node->name, ret);
>
> fwnode_get_name(fwnode), ret);
Or even %pfwP ?
...
> > + snprintf(name, sizeof(name), "%s-%u", node->name, port_num);
>
> snprintf(name, sizeof(name), "%s-%u", fwnode_get_name(fwnode),
> port_num);
Ditto.
--
With Best Regards,
Andy Shevchenko
ce lore.kernel.org. It's really easy for the experienced
maintainer to catch up the whole thread.
Putting _all_ people on all patches may be an overkill.
What people should really get is the cover letter (assuming
that it explains well the structure of the series). The rest
depends.
--
With Best Regards,
Andy Shevchenko
On Tue, Jan 10, 2023 at 01:46:37PM +0100, Andrzej Hajda wrote:
> On 10.01.2023 12:07, Andy Shevchenko wrote:
> > On Tue, Jan 10, 2023 at 11:53:06AM +0100, Andrzej Hajda wrote:
...
> > > + return __xchg(_chain->p_prod_elem,
> > > + (void
201 - 300 of 959 matches
Mail list logo
