) {
> + dev_err(parent, "Failed to register %d v4l2 sd\n",
> led->led_no);
> + return PTR_ERR(led->v4l2_flash);
> + }
> +
> + return 0;
> +}
...
> + } else
> + val = clamp_align(val, MT6370_STRBTO_MINUS,
> MT6370_STRBTO_MAXUS,
> + MT6370_STRBTO_STEPUS);
Missed {}
> +
> +
One blank line is enough.
--
With Best Regards,
Andy Shevchenko
return -EINVAL;
> + }
...
> +static int mt6370_bl_probe(struct platform_device *pdev)
> +{
> + struct mt6370_priv *priv;
> + struct backlight_properties props = {
> + .type = BACKLIGHT_RAW,
> + .scale = BACKLIGHT_SCALE_LINEAR,
> + };
> + int ret;
struct device *dev = &pdev->dev;
will save you a few LoCs.
--
With Best Regards,
Andy Shevchenko
On Fri, Apr 08, 2022 at 03:54:13PM +0200, Maxime Ripard wrote:
> On Fri, Mar 18, 2022 at 04:33:19PM +0200, Andy Shevchenko wrote:
> > On Fri, Mar 18, 2022 at 03:21:45PM +0100, Maxime Ripard wrote:
> > > On Fri, Mar 18, 2022 at 03:42:48PM +0200, Andy Shevchenko wrote:
> >
is, but also with the non-NULL pointers I prefer the old
style without ugly castings.
Instead, you may export the array (in the driver's namespace) and use
&info[ID] pointer for the specific device info.
--
With Best Regards,
Andy Shevchenko
On Tue, Apr 12, 2022 at 02:21:08PM +0300, Andy Shevchenko wrote:
> On Tue, Apr 12, 2022 at 10:07:02AM +0200, Javier Martinez Canillas wrote:
> > On 4/12/22 09:23, Geert Uytterhoeven wrote:
> > > On Mon, Apr 11, 2022 at 11:12 PM Javier Martinez Canillas
> > > wrote:
sport protocols such as SPI.
...
> +EXPORT_SYMBOL_GPL(ssd130x_variants);
What I meant is to use EXPORT_SYMBOL_NS_GPL() here. It might require a separate
patch to move other exports to that namespace first.
--
With Best Regards,
Andy Shevchenko
);
> MODULE_AUTHOR("Javier Martinez Canillas ");
> MODULE_LICENSE("GPL v2");
> +MODULE_IMPORT_NS(DRM_SSD130X);
--
With Best Regards,
Andy Shevchenko
...@linux.intel.com/
>
> In addition, we added a macro to the for declaring the
> linear_range struct simply (see patch v9-0005) and made some changes for
> MT6370 drivers (see v9 section of the change log below).
Your cover letter is dangling. Make sure you are using --cover-letter --thread
when preparing the series.
--
With Best Regards,
Andy Shevchenko
s to read properties in
> bd957x_probe() to the generic device property API as well.
With or without below addressed,
Reviewed-by: Andy Shevchenko
> Signed-off-by: Dmitry Torokhov
>
> diff --git a/drivers/regulator/bd9576-regulator.c
> b/drivers/regulator/bd9576-regulator.c
> index
On Mon, Sep 5, 2022 at 9:33 AM Dmitry Torokhov
wrote:
>
> I would like to stop exporting OF-specific devm_gpiod_get_from_of_node()
> so that gpiolib can be cleaned a bit, so let's switch to the generic
> fwnode property API.
Special thanks for using dev_fwnode().
Reviewed-by
ret = gpiod_set_consumer_name(pcie->reset_gpio, "pcie1-reset");
> > + if (ret) {
> > + dev_err(dev, "Failed to set reset gpio name: %d\n", ret);
> > + return ret;
> > }
Ditto.
--
With Best Regards,
Andy Shevchenko
eset-gpio you have used
> devm_gpiod_get_optional() and here in pci-tegra.c you have used
> devm_fwnode_gpiod_get()? I think that PERST# logic is same in both
> drivers.
It's not the same dev and its node in this case. There is one reset
for _all_ ports, here is the reset on _per port_ basis.
--
With Best Regards,
Andy Shevchenko
On Mon, Sep 5, 2022 at 1:49 PM Andy Shevchenko
wrote:
>
> On Mon, Sep 5, 2022 at 10:23 AM Pali Rohár wrote:
> > On Sunday 04 September 2022 23:30:53 Dmitry Torokhov wrote:
>
> ...
>
> > > - rp->reset_gpio = devm
On Mon, Sep 5, 2022 at 1:53 PM Pali Rohár wrote:
> On Monday 05 September 2022 13:49:21 Andy Shevchenko wrote:
...
> > It's not the same dev and its node in this case. There is one reset
> > for _all_ ports, here is the reset on _per port_ basis.
>
> aardvark is single
with handling secondary fwnodes when gpiolib is taught to handle
> gpios described by swnodes.
I would remove this sentence from all commit messages since it's a
debatable thing and might even not happen, so the above is a pure
speculation.
--
With Best Regards,
Andy Shevchenko
"Request failed for reset GPIO: %d\n", err);
> return err;
> }
--
With Best Regards,
Andy Shevchenko
x = hw_margin[1];
> - hw_margin_min = hw_margin[0];
> + if (count == 1)
> + hw_margin_max = hw_margin[0];
> +
> + if (count == 2) {
> + hw_margin_max = hw_margin[1];
> + hw_margin_min = hw_margin[0];
> + }
> }
--
With Best Regards,
Andy Shevchenko
I'm in favour of the series, but some comments would be good to be addressed.
--
With Best Regards,
Andy Shevchenko
On Mon, Sep 5, 2022 at 4:19 PM Matti Vaittinen wrote:
> On 9/5/22 13:40, Andy Shevchenko wrote:
> > On Mon, Sep 5, 2022 at 9:33 AM Dmitry Torokhov
> > wrote:
...
> >> + vout_mode = device_property_read_bool(pdev->dev.parent,
> >> +
On Mon, Sep 5, 2022 at 6:13 PM Guenter Roeck wrote:
> On 9/5/22 04:09, Andy Shevchenko wrote:
> > On Mon, Sep 5, 2022 at 9:33 AM Dmitry Torokhov
> > wrote:
...
> >> + count = device_property_count_u32(dev->parent,
> >> "rohm,hw-timeout-
On Mon, Sep 5, 2022 at 10:40 PM Dmitry Torokhov
wrote:
> On Mon, Sep 05, 2022 at 01:59:44PM +0300, Andy Shevchenko wrote:
> > On Mon, Sep 5, 2022 at 9:32 AM Dmitry Torokhov
> > wrote:
...
> > > - gpiod = devm_gpiod_get_fro
On Mon, Sep 5, 2022 at 10:51 PM Dmitry Torokhov
wrote:
> On Mon, Sep 05, 2022 at 10:41:40PM +0300, Andy Shevchenko wrote:
> > On Mon, Sep 5, 2022 at 10:40 PM Dmitry Torokhov
> > wrote:
> > > On Mon, Sep 05, 2022 at 01:59:44PM +0300, Andy Shevchenko wrote:
> > >
On Mon, Sep 05, 2022 at 03:07:48PM -0700, Guenter Roeck wrote:
> On 9/5/22 12:55, Andy Shevchenko wrote:
> > On Mon, Sep 5, 2022 at 10:51 PM Dmitry Torokhov
> > wrote:
> > > On Mon, Sep 05, 2022 at 10:41:40PM +0300, Andy Shevchenko wrote:
> > > > On Mon, Sep
TO_STEP_US 32000
> > > +#define MT6370_STRBTO_MAX_US 2432000
>
> Hi Jingoo,
>
> This coding style is in accordance with Andy's opinion in this mail:
> https://lore.kernel.org/linux-arm-kernel/CAHp75Vciq4M4kVrabNV9vTLLcd1vR=bme8jledaf9mkrtpc...@mail.gmail.com/
True.
--
With Best Regards,
Andy Shevchenko
On Wed, Jul 13, 2022 at 12:53 PM ChiaEn Wu wrote:
> Andy Shevchenko 於 2022年7月5日 週二 清晨5:14寫道：
> > On Mon, Jul 4, 2022 at 7:43 AM ChiaEn Wu wrote:
Please, remove unneeded context when replying!
...
> > > + brightness_val[0] = (brightness - 1) &
>
On Thu, Jul 14, 2022 at 9:13 AM ChiaEn Wu wrote:
> Andy Shevchenko 於 2022年7月13日 週三 晚上8:07寫道：
> > On Wed, Jul 13, 2022 at 12:53 PM ChiaEn Wu wrote:
> > > Andy Shevchenko 於 2022年7月5日 週二 清晨5:14寫道：
> > > > On Mon, Jul 4, 2022 at 7:43 AM ChiaEn Wu wrote:
Pleas
On Thu, Jul 14, 2022 at 11:27 AM Andy Shevchenko
wrote:
>
> On Thu, Jul 14, 2022 at 9:13 AM ChiaEn Wu wrote:
> > Andy Shevchenko 於 2022年7月13日 週三 晚上8:07寫道：
...
> > I have tried two methods
On Thu, Jul 14, 2022 at 11:47 AM Daniel Thompson
wrote:
>
> On Thu, Jul 14, 2022 at 11:27:07AM +0200, Andy Shevchenko wrote:
> > On Thu, Jul 14, 2022 at 9:13 AM ChiaEn Wu wrote:
> > > I have tried two metho
On Thu, Jul 14, 2022 at 11:43 AM Andy Shevchenko
wrote:
> On Thu, Jul 14, 2022 at 11:27 AM Andy Shevchenko
> wrote:
> > On Thu, Jul 14, 2022 at 9:13 AM ChiaEn Wu wrote:
> > > Andy Shevchenko 於 2022年7月13日 週三 晚上8:07寫道：
...
> > > * prop_val = 1 --> 1
iver, display bias
> voltage supply, one general purpose LDO, and the USB Type-C & PD controller
> complies with the latest USB Type-C and PD standards.
FWIW,
Reviewed-by: Andy Shevchenko
> Signed-off-by: ChiYuan Huang
> ---
> v5
>
> - Add the comma in the last REGM
irq\n");
> + }
> +
> + device_init_wakeup(dev, true);
> + dev_pm_set_wake_irq(dev, priv->irq);
> +
> + return 0;
> +}
> +
> +static int mt6370_tcpc_remove(struct platform_device *pdev)
> +{
> + struct mt6370_priv *priv = platform_get_drvdata(pdev);
> + disable_irq(priv->irq);
Why?
An ugly workaround due to ordering issues in ->probe()?
> + tcpci_unregister_port(priv->tcpci);
> + dev_pm_clear_wake_irq(&pdev->dev);
> + device_init_wakeup(&pdev->dev, false);
> +
> + return 0;
> +}
--
With Best Regards,
Andy Shevchenko
o have a temporary variable
struct device *dev = &pdev->dev;
It will shorten some lines.
> + struct mt6370_adc_data *priv;
> + struct iio_dev *indio_dev;
> + struct regmap *regmap;
> + int ret;
> +}
--
With Best Regards,
Andy Shevchenko
gt;
> I propose, instead:
>
> enum mt6370_state {
> STATE_OFF = 0,
> STATE_KEEP,
> STATE_ON,
> STATE_MAX,
Usually we don't put commas at the terminator entries.
> };
--
With Best Regards,
Andy Shevchenko
be_out;
> +
> + mt6370_chg_pwr_rdy_check(priv);
> +
> + return 0;
> +
> +probe_out:
> + cancel_delayed_work_sync(&priv->mivr_dwork);
> + flush_workqueue(priv->wq);
> + destroy_workqueue(priv->wq);
> + mutex_destroy(&priv->attach_lock);
> +
> + return ret;
> +}
> +
> +static int mt6370_chg_remove(struct platform_device *pdev)
> +{
> + struct mt6370_priv *priv = platform_get_drvdata(pdev);
> +
> + cancel_delayed_work_sync(&priv->mivr_dwork);
> + flush_workqueue(priv->wq);
> + destroy_workqueue(priv->wq);
> + mutex_destroy(&priv->attach_lock);
> +
> + return 0;
> +}
--
With Best Regards,
Andy Shevchenko
if (ret) {
> + dev_err(priv->dev,
> + "led %d, no color specified\n",
> + led->index);
> + return ret;
return dev_err_probe(...) ; ?
Ditto for many places in your entire series.
> + }
...
> + priv = devm_kzalloc(&pdev->dev,
> + struct_size(priv, leds, count), GFP_KERNEL);
At least one parameter can be placed on the previous line.
> + if (!priv)
> + return -ENOMEM;
--
With Best Regards,
Andy Shevchenko
-EINVAL;
Ditto.
> + }
...
> + ret = fwnode_property_read_u32(init_data->fwnode, "led-max-microamp",
> + &val);
One line?
...
> + val = clamp_align(val, MT6370_STRBTO_MIN_US,
> MT6370_STRBTO_MAX_US,
> + MT6370_STRBTO_STEP_US);
I would name it mt6370_clamp() to avoid potential collision in the
global namespace in the future.
--
With Best Regards,
Andy Shevchenko
On Mon, Jul 18, 2022 at 10:08 AM ChiYuan Huang wrote:
> On Fri, Jul 15, 2022 at 03:10:42PM +0200, Andy Shevchenko wrote:
> > On Fri, Jul 15, 2022 at 1:28 PM ChiaEn Wu wrote:
...
> > > This commit add support for the Type-C & Power Delivery controller in
> >
x1E0
> +
> +#define MT6370_VENID_MASK GENMASK(7, 4)
> +
> +#define MT6370_NUM_IRQREGS 16
> +#define MT6370_USBC_I2CADDR0x4E
> +#define MT6370_REG_ADDRLEN 2
> +#define MT6370_REG_MAXADDR 0x1FF
These two more logically to have near to other _REG_* definitions above.
--
With Best Regards,
Andy Shevchenko
LE_MASK : 0);
Why not positive conditional?
enable ? 0 : mask
> +}
...
> + ret = devm_add_action_or_reset(dev, mt6370_unregister_tcpci_port,
> + priv->tcpci);
I believe nothing bad will happen if you put it on one line.
--
With Best Regards,
Andy Shevchenko
e new standard/hardware decides to use 0x7 for 100mA (hypothetically)?
So, please use switch cases or other robust methods.
--
With Best Regards,
Andy Shevchenko
dev_name(priv->dev), priv);
> +
Redundant blank line.
> + if (ret < 0)
> + return dev_err_probe(priv->dev, ret,
> + "Failed to request irq %s\n",
> +mt6370_chg_irqs[i].name);
> + }
--
With Best Regards,
Andy Shevchenko
&stat_str)) {
ret = fwnode_...(...);
if (!ret)
> + ret = match_string(states, ARRAY_SIZE(states), stat_str);
> + if (ret < 0)
> + ret = STATE_OFF;
> +
> + led->default_state = ret;
> + }
...
> + int i = 0, ret;
unsigned int i = 0;
int ret;
--
With Best Regards,
Andy Shevchenko
On Mon, Jul 25, 2022 at 10:30 AM ChiaEn Wu wrote:
> On Mon, Jul 25, 2022 at 4:00 PM Andy Shevchenko
> wrote:
...
> > > +#define MT6370_REG_DEV_INFO0x100
> > > +#define MT6370_REG_CHG_IRQ10x1C0
> > > +#define MT6370_REG_CHG_MASK1 0x1E0
> &g
if (ret)
> + goto unlock;
> + }
> + }
> +
> + ret = regmap_update_bits(priv->regmap, MT6370_REG_FLEDEN,
> +enable_mask, val);
> + if (ret)
> + goto unlock;
> +
> + priv->fled_torch_used = curr;
> +
> +unlock:
> + mutex_unlock(&priv->lock);
> + return ret;
> +}
...
> + struct v4l2_flash_config v4l2_config = {0};
0 is not needed.
--
With Best Regards,
Andy Shevchenko
(prev && !curr)
> + udelay(500);
This still remains unanswered, why in the first place we allow
switching, and a busy loop in the other place?
--
With Best Regards,
Andy Shevchenko
GPIOD_OUT_HIGH);
> + if (IS_ERR(priv->enable_gpio))
> + dev_err(dev, "Failed to get 'enable' gpio\n");
What does this mean? Shouldn't be
return dev_err_probe()?
--
With Best Regards,
Andy Shevchenko
On Mon, Jul 25, 2022 at 11:06 AM ChiaEn Wu wrote:
> On Mon, Jul 25, 2022 at 4:43 PM Andy Shevchenko
> wrote:
...
> > > > > +#define MT6370_REG_DEV_INFO0x100
> > > > > +#define MT6370_REG_CHG_IRQ10x1C0
> > > > > +#define MT6370_R
refine the description to
> "For the flash to turn on/off, need to wait for 5ms/500us analog settling
> time.
> If any flash led is already used, then the analog is settled done, we
> don't need to wait again."
> is it answer the question?
No. I'm talking from the Linux APIs perspective. There is a huge
difference between those branches. Please, conduct research, read
documentation to understand what my question is about.
--
With Best Regards,
Andy Shevchenko
On Tue, Jul 26, 2022 at 1:46 PM ChiaEn Wu wrote:
> On Mon, Jul 25, 2022 at 4:41 PM Andy Shevchenko
> wrote:
...
> > > +struct mt6370_led {
> > > + union {
> > > + struct led_classdev isink;
> > > + struct led_classde
On Wed, Jul 27, 2022 at 9:37 AM ChiaEn Wu wrote:
> On Tue, Jul 26, 2022 at 8:18 PM Andy Shevchenko
> wrote:
>
> ...
>
> > > Just for saving memory space.
> > > Because these led_classdevs do not be used at the same time.
> > > Or do you think i
#x27;s a pointer, but what puzzles me, why it can't be declared as a such:
struct device_node *node;
?
> And it's not really a "node" but an "offset", right?
Seems no.
--
With Best Regards,
Andy Shevchenko
dev/earlycon.c
> >
> > That should be a rename, not a delete/create, right?
>
> Should this change be split into two separate commits,
> one for moving the file and the second for making changes?
I think it's a pointer to use `git format-patch -M -C ...` when
preparing patches.
--
With Best Regards,
Andy Shevchenko
+ else
> + memset(dst, 0, (info.depth / 8));
> + dst += (info.depth / 8);
> + }
> +}
Wondering if we already have something like this in DRM/fbdev and can
split into a generic helper.
...
> + ret = sscanf(device->opt
On Fri, Jul 29, 2022 at 8:17 AM szuni chen wrote:
> Andy Shevchenko 於 2022年7月25日 週一 下午4:51寫道：
> > On Fri, Jul 22, 2022 at 12:25 PM ChiaEn Wu wrote:
> > >
> > > From: Alice Chen
...
> > > Signed-off-by: Alice Chen
> >
> > This SoB chain
On Fri, Jul 29, 2022 at 9:57 AM Greg Kroah-Hartman
wrote:
> On Thu, Jul 28, 2022 at 11:04:24PM +0200, Andy Shevchenko wrote:
> > On Thu, Jul 28, 2022 at 4:41 PM Greg Kroah-Hartman
> > wrote:
> > > On Thu, Jul 28, 2022 at 05:28:18PM +0300, Markuss Broks wrote:
...
>
On Sat, Jul 30, 2022 at 10:55 AM Markuss Broks wrote:
> On 7/29/22 00:19, Andy Shevchenko wrote:
> > On Thu, Jul 28, 2022 at 4:32 PM Markuss Broks
> > wrote:
...
> I suppose we could use something like:
>
> if (region_intersects() == REGION_INTERSECTS)
Yes.
...
&
the idea would
> then be to make x86 ioremap be UC instead of UC-, again matching what the
> other architectures do already.
I think it's right thing to do, i.e. assume that ioremap() always does strong
UC independently on MTRR settings.
--
With Best Regards,
Andy Shevchenko
p-table.
>
> Since the lookup-table is attached to the i915 PCI device it really
> should be part of the i915 driver, this will also allow us to extend
> it with GPIOs from other sources when necessary.
Reviewed-by: Andy Shevchenko
One nit below.
> Signed-off-by: Hans de
I believe there will be no (significant) changes in the driver Hans
touched. For the record it seems only Hans is touching drivers for old Intel
platforms (such as Baytrail and Cherryview).
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
9c6d1f49ade2f3 ("drm/drm_panel: fix EXPORT of
> drm_panel_of_backlight") is fixing drm_panel_of_backlight(), but the
> error above is for backlight_device_register().
>
> From what I can tell, that commit is actually the cause of the error -
> now intel_backlight_device
On Tue, Dec 17, 2019 at 5:28 PM Jani Nikula wrote:
> On Tue, 17 Dec 2019, Andy Shevchenko wrote:
> > On Tue, Dec 17, 2019 at 1:56 PM Steven Price wrote:
> > I think the proper one is to have s/IS_ENABLED/IS_REACHABLE/.
> > It fixes issue for me.
>
> As discusse
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/drm_panel.c | 2 +-
include/drm/drm_panel.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index 79ff3fdf6f6e..8c7bac85a793 10064
CH_REPORTS) :
+
_MASKED_BIT_DISABLE(GEN12_OAG_OA_DEBUG_DISABLE_CTX_SWITCH_REPORTS)));
intel_uncore_write(uncore, GEN12_OAG_OAGLBCTXCTRL, periodic ?
(GEN12_OAG_OAGLBCTXCTRL_COUNTER_RESUME |
--
2.24.0
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
0
greater than 65536
The crucial thing is to check the transfer size against maximum DMA length
of the master.
Please, fix.
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Oct 15, 2019 at 05:32:36PM +0300, Andy Shevchenko wrote:
> On Fri, Jul 19, 2019 at 05:59:10PM +0200, Noralf Trønnes wrote:
> > spi-bcm2835 can handle >64kB buffers now so there is no need to check
> > ->max_dma_len. The tinydrm_spi_max_transfer_size() max_len argume
On Tue, Oct 15, 2019 at 05:41:53PM +0200, Noralf Trønnes wrote:
> Den 15.10.2019 16.32, skrev Andy Shevchenko:
> > On Fri, Jul 19, 2019 at 05:59:10PM +0200, Noralf Trønnes wrote:
> >> spi-bcm2835 can handle >64kB buffers now so there is no need to check
&g
On Tue, Oct 15, 2019 at 06:05:16PM +0200, Daniel Vetter wrote:
> On Tue, Oct 15, 2019 at 5:59 PM Andy Shevchenko
> wrote:
> > On Tue, Oct 15, 2019 at 05:41:53PM +0200, Noralf Trønnes wrote:
> > > Den 15.10.2019 16.32, skrev Andy Shevchenko:
> > > > On Fri, Jul 19,
On Tue, Oct 15, 2019 at 05:57:20PM +0200, Daniel Vetter wrote:
> On Tue, Oct 15, 2019 at 05:41:53PM +0200, Noralf Trønnes wrote:
> > Den 15.10.2019 16.32, skrev Andy Shevchenko:
> > > On Fri, Jul 19, 2019 at 05:59:10PM +0200, Noralf Trønnes wrote:
> > >> spi-bcm2835 c
On Wed, Oct 16, 2019 at 07:44:51PM +0200, Daniel Vetter wrote:
> On Wed, Oct 16, 2019 at 6:13 PM Andy Shevchenko
> wrote:
> > On Tue, Oct 15, 2019 at 05:57:20PM +0200, Daniel Vetter wrote:
> > max_transfer_size should be a function. In that case it works.
>
> Why
> Fix this by setting the overall max transfer size to the DMA limit,
> but only when the controller runs in DMA mode.
>
Thank you, Daniel!
> Fixes: e143364b4c17 ("drm/tinydrm: Remove tinydrm_spi_max_transfer_size()")
> Cc: Sam Ravnborg
> Cc: Noralf Trønnes
> Cc
On Sat, Oct 19, 2019 at 12:58 PM Bartosz Golaszewski wrote:
>
> From: Bartosz Golaszewski
>
> Remove a double newline from the driver.
>
Reviewed-by: Andy Shevchenko
> Signed-off-by: Bartosz Golaszewski
> ---
> drivers/video/backlight/gpio_backlight.c | 1 -
>
On Thu, Oct 17, 2019 at 10:06:38AM +0300, Andy Shevchenko wrote:
> On Thu, Oct 17, 2019 at 08:44:26AM +0200, Daniel Vetter wrote:
> > In DMA mode we have a maximum transfer size, past that the driver
> > falls back to PIO (see the check at the top of pxa2xx_spi_transfer_one).
>
On Wed, Feb 05, 2020 at 07:33:22PM +0200, Laurent Pinchart wrote:
> Hi Andy,
>
> Thank you for the patch.
>
> On Wed, Feb 05, 2020 at 11:32:26AM +0200, Andy Shevchenko wrote:
> > This file doesn't need everything provided by .
> > All it needs are s
This file doesn't need everything provided by .
All it needs are some types, which are provided by .
Drop unneeded completely.
Signed-off-by: Andy Shevchenko
---
v3: Drop header completely (Laurent)
include/linux/platform_data/shmob_drm.h | 2 --
1 file changed, 2 deletions(-)
diff --
gt; -- : --
>
>
> I've attached 2 drivers:
> - gpio/pinctrl: is more or less finished
> - display: needs a lot more work
Can regmap-usb be used for drivers/mfd/dln2.c for example?
--
With Best Regards,
Andy Shevchenko
_
ay to cover other
possible users.
I Cc this to people from that discussion.
[1]:
https://lore.kernel.org/dri-devel/cal_quvrknssvvxn3q_se0hrziw2otns3ennoehyhvcicrq9...@mail.gmail.com/
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-
On Thu, Feb 06, 2020 at 01:12:32PM +0200, Andy Shevchenko wrote:
> This file doesn't need everything provided by .
> All it needs are some types, which are provided by .
>
> Drop unneeded completely.
Any comments on this?
>
> Signed-off-by: Andy Shevchenko
> ---
&g
ls
> L: linux-me...@vger.kernel.org
> --
> 2.17.1
>
--
With Best Regards,
Andy Shevchenko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
uncs;
> + ctx->bridge.of_node = dev->of_node;
> +
> + ret = devm_request_threaded_irq(dev, client->irq, NULL,
> + it66121_irq_threaded_handler,
> + IRQF_SHARED | IRQF_TRIGGER_LOW |
> +
On Thu, Mar 12, 2020 at 2:56 AM Laurent Pinchart
wrote:
> On Wed, Mar 11, 2020 at 03:55:35PM +0200, Andy Shevchenko wrote:
> > On Wed, Mar 11, 2020 at 01:51:34PM +0100, Phong LE wrote:
> > > This commit is a simple driver for bridge HMDI it66121.
> > > The input fo
The spi_register_driver() will set the ->owner member to THIS_MODULE.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/tiny/st7735r.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/tiny/st7735r.c b/drivers/gpu/drm/tiny/st7735r.c
index a844cde6d14a..3cd9b8d9888d 100
There is one OF call in the driver that limits its area of use.
Replace it to generic device_get_match_data() and get rid of OF dependency.
While here, cast SPI driver data to certain enumerator type.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/tiny/repaper.c | 11 ++-
1 file
The spi_register_driver() will set the ->owner member to THIS_MODULE.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/tiny/repaper.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/tiny/repaper.c b/drivers/gpu/drm/tiny/repaper.c
index fd9e95ce3201..4a497203923f 100
There is one OF call in the driver that limits its area of use.
Replace it to generic device_get_match_data() and get rid of OF dependency.
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/tiny/st7735r.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm
On Fri, Jan 24, 2020 at 06:06:37PM +0100, Sam Ravnborg wrote:
> Hi Andy.
>
> On Wed, Jan 22, 2020 at 12:54:01PM +0200, Andy Shevchenko wrote:
> > The spi_register_driver() will set the ->owner member to THIS_MODULE.
> >
> > Signed-off-by: Andy Shevchenko
>
>
On Fri, Jan 24, 2020 at 05:42:33PM +0100, Sam Ravnborg wrote:
> On Wed, Jan 22, 2020 at 12:54:00PM +0200, Andy Shevchenko wrote:
> > There is one OF call in the driver that limits its area of use.
> > Replace it to generic device_get_match_data() and get rid of OF dependency.
>
On Fri, Jan 24, 2020 at 07:18:12PM +0100, Sam Ravnborg wrote:
> On Fri, Jan 24, 2020 at 07:31:34PM +0200, Andy Shevchenko wrote:
> > On Fri, Jan 24, 2020 at 05:42:33PM +0100, Sam Ravnborg wrote:
> > > On Wed, Jan 22, 2020 at 12:54:00PM +0200, Andy Shevchenko wrote:
> > >
The spi_register_driver() will set the ->owner member to THIS_MODULE.
Cc: Noralf Trønnes
Cc: dri-devel@lists.freedesktop.org
Cc: David Airlie
Cc: Daniel Vetter
Signed-off-by: Andy Shevchenko
Reviewed-by: David Lechner
Reviewed-by: Sam Ravnborg
---
v2: Add tags (Sam, David)
drivers/gpu/
There is one OF call in the driver that limits its area of use.
Replace it to generic device_get_match_data() and get rid of OF dependency.
Cc: Noralf Trønnes
Cc: dri-devel@lists.freedesktop.org
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sam Ravnborg
Signed-off-by: Andy Shevchenko
Acked-by
The spi_register_driver() will set the ->owner member to THIS_MODULE.
Cc: Noralf Trønnes
Cc: dri-devel@lists.freedesktop.org
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sam Ravnborg
Signed-off-by: Andy Shevchenko
Reviewed-by: David Lechner
---
v2: Add tag (David)
drivers/gpu/drm/tiny/st7735
Cc: David Lechner
Signed-off-by: Andy Shevchenko
Reviewed-by: Sam Ravnborg
---
v2: Replace cryptic macro with comment, add Rb tag (Sam)
drivers/gpu/drm/tiny/repaper.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/tiny/repaper.c b/drivers/gpu/drm
On Wed, Jan 29, 2020 at 09:29:14PM +0100, Sam Ravnborg wrote:
> On Mon, Jan 27, 2020 at 11:39:39AM +0200, Andy Shevchenko wrote:
> > On Fri, Jan 24, 2020 at 07:18:12PM +0100, Sam Ravnborg wrote:
> > > On Fri, Jan 24, 2020 at 07:31:34PM +0200, Andy Shevchenko wrote:
> > >
On Tue, Feb 04, 2020 at 08:26:21PM +0200, Laurent Pinchart wrote:
> On Tue, Feb 04, 2020 at 06:39:34PM +0100, Geert Uytterhoeven wrote:
> > On Tue, Feb 4, 2020 at 5:20 PM Andy Shevchenko wrote:
> > > Replace with appropriate types.h.
> >
> > Thanks for your patch!
Replace with appropriate types.h.
Signed-off-by: Andy Shevchenko
---
include/linux/platform_data/shmob_drm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/platform_data/shmob_drm.h
b/include/linux/platform_data/shmob_drm.h
index fe815d7d9f58..08605fdb2226
This file doesn't need everything provided by .
All it needs are some types, which are provided by .
Note, already includes , but
not relying on implicit includes is indeed a good thing.
Signed-off-by: Andy Shevchenko
---
v2: Update commit message (Geert, Laurent)
include/linux/platform
On Tue, Oct 01, 2019 at 02:58:31PM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
Reviewed-by: Andy Shevchenko
> We no longer use any symbols from of_gpio.h. Remove this include.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> drivers/video/backlight
l tree?
>
Entire series (or a single patch) makes sense to me.
Thanks for fixing this old hardware!
FWIW,
Reviewed-by: Andy Shevchenko
> Regards,
>
> Hans
>
> p.s.
>
> The promised background info:
>
> We have this long standing issue where instead of looking
Make use of device property API in this driver so that both OF based
system and ACPI based system can use this driver.
Signed-off-by: Andy Shevchenko
---
drivers/staging/fbtft/fbtft-core.c | 105 -
1 file changed, 58 insertions(+), 47 deletions(-)
diff --git a
propriate.
Signed-off-by: Andy Shevchenko
---
drivers/staging/fbtft/fbtft-core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/fbtft/fbtft-core.c
b/drivers/staging/fbtft/fbtft-core.c
index 61f0286fb157..2122c4407bdb 100644
--- a/drivers/staging/fbtft/fbtft-core.c
+++ b/drivers/s
ys be true.
Due to above drop useless #ifdef CONFIG_OF and therefore dead code.
Signed-off-by: Andy Shevchenko
---
drivers/staging/fbtft/fbtft-core.c | 19 ++-
1 file changed, 2 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/fbtft/fbtft-core.c
b/drivers/staging/
301 - 400 of 1147 matches
Mail list logo
