future support of
UART DMA on Intel Quark.
The Intel Quark UART DMA support is based on bits taking from BSP code
published by Intel earlier.
The driver does not use any specific power management. PCI core takes care of
the default behaviour during suspend and resume.
Signed-off-by: Andy Shevchenko
I'm pretty sure that Documentation/pinctrl.txt would be better maintained by
pinctrl subsystem.
Signed-off-by: Andy Shevchenko
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9040236..c59d978 100644
--- a/MAINTAINERS
+++ b/MAINTA
+ wg->chip.parent = dev;
> + wg->chip.dbg_show = wcove_gpio_dbg_show;
> + wg->regmap = pmic->regmap;
> +
> + retval = devm_gpiochip_add_data(&pdev->dev, &wg->chip, wg);
> + if (retval) {
> + dev_warn(&pdev->dev, "add gpio chip error: %d\n", retval);
> + return retval;
> + }
> +
> + gpiochip_irqchip_add(&wg->chip, &wcove_irqchip, 0,
> +handle_simple_irq, IRQ_TYPE_NONE);
> +
> + virq = regmap_irq_get_virq(wg->regmap_irq_chip, irq);
> + if (virq < 0) {
> + dev_err(&pdev->dev,
> + "failed to get virtual interrupt=%d\n", irq);
> + retval = virq;
> + goto out_remove_gpio;
> + }
> +
> + retval = devm_request_threaded_irq(&pdev->dev, virq,
> + NULL, wcove_gpio_irq_handler,
> + IRQF_ONESHOT, pdev->name, wg);
> +
> + if (retval) {
> + dev_warn(&pdev->dev, "request irq failed: %d, virq: %d\n",
> + retval, virq);
Non fatal? Needs an explanation in the comment.
> + goto out_remove_gpio;
> + }
> +
> + return 0;
> +
> +out_remove_gpio:
> + gpiochip_remove(&wg->chip);
> + return retval;
BLUNDER! You are using devm_*() API.
> +}
> +
> +static int wcove_gpio_remove(struct platform_device *pdev)
> +{
> + struct wcove_gpio *wg = platform_get_drvdata(pdev);
> +
> + gpiochip_remove(&wg->chip);
Ditto.
> + return 0;
> +}
> +
> +static struct platform_driver wcove_gpio_driver = {
> + .driver = {
> + .name = "bxt_wcove_gpio",
No PM?
> + },
> + .probe = wcove_gpio_probe,
> + .remove = wcove_gpio_remove,
> +};
--
With Best Regards,
Andy Shevchenko
0 << dsaf_dev->reset_offset;
> + else
> + reg_val_2 = 0x40 << dsaf_dev->reset_offset;
reg_val_1 = 0x15540;
reg_val_2 = AE_IS_VER1(dsaf_dev->dsaf_ver) ? 0x100 : 0x40;
reg_val_1 <<= dsaf_dev->reset_offset;
reg_val_2 <<= dsaf_dev-
&
> obviously wrong
> with the mail format. Also tried to reduce down the number of people
> on the
> To/Cc list
There is still _a lot_ of addresses in the Cc and To fields.
--
Andy Shevchenko
Intel Finland Oy
DSAF_PRIO_NR] = hw_stats-
> >tx_pfc[i];
> + }
Two different approaches how to assign data. Above uses 2 for-loops,
here you put everything to one.
> + p[29] = hw_stats->tx_pkts;
> + return &p[30];
> + }
>
> + p[13] = hw_stats->tx_pkts;
> return &p[14];
> }
--
Andy Shevchenko
Intel Finland Oy
On Tue, Jun 21, 2016 at 6:10 PM, Bryan O'Donoghue
wrote:
> On Mon, 2016-06-20 at 12:17 +0300, Andy Shevchenko wrote:
>> This is combined series of two things:
>> - split out the Intel LPSS specific driver from 8250_pci into
>> 8250_lpss
>> - enable DMA support on
Merrifield2 is actually Moorefield.
Rename it accodingly and drop tail digit from Merrifield1.
Cc: Dave Hansen
Signed-off-by: Andy Shevchenko
---
arch/x86/include/asm/intel-family.h | 4 ++--
arch/x86/platform/atom/punit_atom_debug.c | 2 +-
drivers/pci/pci-mid.c | 2
Tell SCU that we are about powering off the device.
Signed-off-by: Andy Shevchenko
---
arch/x86/include/asm/intel-mid.h| 2 ++
arch/x86/include/asm/intel_scu_ipc.h| 2 ++
arch/x86/platform/intel-mid/intel-mid.c | 5 +
arch/x86/platform/intel-mid/pwr.c | 27
Tell SCU that we are about powering off the device.
Signed-off-by: Andy Shevchenko
---
- change abbrevation from PMU to PWRMU
arch/x86/include/asm/intel-mid.h| 2 ++
arch/x86/include/asm/intel_scu_ipc.h| 2 ++
arch/x86/platform/intel-mid/intel-mid.c | 5 +
arch/x86/platform
Merrifield2 is actually Moorefield.
Rename it accordingly and drop tail digit from Merrifield1.
Cc: Dave Hansen
Signed-off-by: Andy Shevchenko
---
- fix spelling typo in commit message
arch/x86/include/asm/intel-family.h | 4 ++--
arch/x86/platform/atom/punit_atom_debug.c | 2
lines by functional changes and the
first patch in such cases just makes a noise. More important, easier way
to back port if anyone is interested in that.
--
Andy Shevchenko
Intel Finland Oy
gt; chip->write_regs = pca953x_write_regs_8;
> - else if (chip->gpio_chip.ngpio >= 24)
> + chip->read_regs = pca953x_read_regs_8;
> + } else if (chip->gpio_chip.ngpio >= 24) {
> chip->write_regs = pca953x_write_regs_24;
> + chip->read_regs = pca953x_read_regs_24;
> + } else {
> + chip->read_regs = pca953x_read_regs_16;
> + }
For sake of consolidation stuff can we move write_regs_16 variants here?
It might require to refactor patch 3 as well
>
> if (PCA_CHIP_TYPE(chip->driver_data) == PCA953X_TYPE)
> ret = device_pca953x_init(chip, invert);
--
Andy Shevchenko
Intel Finland Oy
e(struct i2c_client
> *client,
> else if (chip->gpio_chip.ngpio >= 24)
> chip->write_regs = pca953x_write_regs_24;
>
> - if (chip->chip_type == PCA953X_TYPE)
> + if (PCA_CHIP_TYPE(chip->driver_data) == PCA953X_TYPE)
> r
pca953x: remove an unused variable
> gpio: pca953x: refactor pca953x_read_regs()
>
> drivers/gpio/gpio-pca953x.c | 270 ++-----
> -
> 1 file changed, 136 insertions(+), 134 deletions(-)
>
--
Andy Shevchenko
Intel Finland Oy
entry->name);
> return;
> + }
>
> spi_info.platform_data = pdata;
> if (dev->delay)
> @@ -398,8 +403,10 @@ static void __init sfi_handle_i2c_dev(struct
> sfi_device_table_entry *pentry,
> i2c_info.addr);
> pdat
On Wed, 2016-09-07 at 13:40 +0200, Bartosz Golaszewski wrote:
> 2016-09-07 13:36 GMT+02:00 Andy Shevchenko tel.com>:
> >
> > On Wed, 2016-09-07 at 11:24 +0200, Bartosz Golaszewski wrote:
> > >
> > > The chip_type variable in struct pca953x_chip is no longer
Tell SCU that we are about powering off the device.
Signed-off-by: Andy Shevchenko
---
v3:
- fix type of variable (lkp)
v2:
- change abbrevation from PMU to PWRMU
arch/x86/include/asm/intel-mid.h| 2 ++
arch/x86/include/asm/intel_scu_ipc.h| 2 ++
arch/x86/platform/intel-mid/intel
ngpio >= 24) {
> chip->write_regs = pca953x_write_regs_24;
> - else
> + chip->read_regs = pca953x_read_regs_24;
> + } else {
> chip->write_regs = chip->chip_type == PCA953X_TYPE ?
> pca953x_write_regs_16 :
> pca957x_write_regs_16;
> + chip->read_regs = pca953x_read_regs_16;
> + }
Would you move {} to the previous patch?
--
Andy Shevchenko
Intel Finland Oy
gs = pca957x_write_regs_16;
> chip->read_regs = pca953x_read_regs_16;
I would also move this to previous patch.
--
Andy Shevchenko
Intel Finland Oy
t fixes a couple coding style issues. The second
> removes a couple unnecessary switches. Last three refactor the
> read/write_regs functions to avoid if-elses by using function pointers
> to smaller, specialized routines.
Still few style comments, otherwise
Reviewed-by: Andy Shevchenko
8);
> reg_val[bank] = (reg_val[bank] & ~bankmask) |
> bankval;
> }
> }
> +
> ret = i2c_smbus_write_i2c_block_data(chip->client,
> chip->offset->output <<
> bank_shift,
> NBANK(chip), reg_val);
--
Andy Shevchenko
Intel Finland Oy
) or
> > > supply all the mappings for device supplies before you register a
> > > device. If you don't call regulator_has_full_constraints()
> > > missing regulators will always defer so you would need to provide
> > > a fixed voltage regulator for it.
...and fixed regulator is also deferred due to GPIO is not ready _yet_.
--
Andy Shevchenko
Intel Finland Oy
On Wed, 2016-09-07 at 15:53 +0100, Bryan O'Donoghue wrote:
> On Wed, 2016-09-07 at 15:39 +0300, Andy Shevchenko wrote:
> >
> > +#define IPCMSG_COLD_OFF0x80/* Only for Tangier
> > */
>
> Andy, I'm wondering are these magic numbers document
igned-off-by: Bartosz Golaszewski
> Reviewed-by: Andy Shevchenko
> ---
> drivers/gpio/gpio-pca953x.c | 22 --
> 1 file changed, 12 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
> index b08ed52..07
On Tue, 2016-08-23 at 08:53 -0500, Dinh Nguyen wrote:
> Hi Andy,
>
> On 08/17/2016 06:14 AM, Andy Shevchenko wrote:
> >
> >
> > I sent a v2 of the series for internal review, same you may found on
> > [1]. If Heikki is okay to that I'll send it here.
> &
platform_ipc.c.
> Yes. But platform_ipc.c implements custom ipc handler for audio ipc
> device. Even though there are duplications between custom handler and
> generic handler in sfi.c, I think its bit early to optimize this. I
> think we should revisit this once we have one more implementation of
> custom ipc handler.
Definitely it's out of scope for now.
--
Andy Shevchenko
Intel Finland Oy
th drivers.
Fixes: ca22312dc840 ("x86/platform/intel-mid: Extend PWRMU to support Penwell")
Signed-off-by: Andy Shevchenko
---
arch/x86/platform/intel-mid/pwr.c | 1 +
drivers/pci/pci-mid.c | 5 +
2 files changed, 6 insertions(+)
diff --git a/arch/x86/platform/intel-m
On Penwell SRAM has to be powered on, otherwise it prevents booting.
Fixes: ca22312dc840 ("x86/platform/intel-mid: Extend PWRMU to support Penwell")
Signed-off-by: Andy Shevchenko
---
arch/x86/platform/intel-mid/pwr.c | 45 +++
1 file changed, 36
ret = pca953x_read_regs(chip, PCA957X_DIRECTION, chip-
> >reg_direction);
Bu we may use chip->regs->direction here, right? And output before.
> if (ret)
> goto out;
>
--
Andy Shevchenko
Intel Finland Oy
On Thu, 2016-09-08 at 15:27 +0300, Andy Shevchenko wrote:
> On Thu, 2016-09-08 at 12:48 +0200, Bartosz Golaszewski wrote:
> >
> > The register offset defines for the pca953x and pca957x expander
> > families should have the same names to better reflect their similar
> >
s ok for you, my next patch will be
> something like
> this:
> ...
> config P2SB
> bool
> depends on PCI
> ...
> In p2sb.c, module.h header file will be removed as well.
> Hi Andy, please provide your comments and/or concerns if any. Thanks.
--
Andy Shevchenko
Intel Finland Oy
l-mid/device_libs/platform_tca6416.c
> @@ -34,8 +34,12 @@ static void *tca6416_platform_data(void *info)
> gpio_base = get_gpio_by_name(base_pin_name);
> intr = get_gpio_by_name(intr_pin_name);
>
> - if (gpio_base < 0)
> + if (gpio_base < 0) {
> + pr_err("%s: Unknown GPIO base number, falling back to
> dynamic"
> + "allocation\n", __func__);
Ditto.
--
Andy Shevchenko
Intel Finland Oy
e when I tried to use it...
It might be that person is no longer working for Intel, though I think
It would be better log message for that.
--
With Best Regards,
Andy Shevchenko
board_gpio.c
> create mode 100644 drivers/platform/x86/up_board_gpio.h
> create mode 100644 drivers/platform/x86/up_board_leds.c
> create mode 100644 drivers/platform/x86/up_board_leds.h
> create mode 100644 drivers/platform/x86/up_board_pinctrl.c
> create mode 100644 drivers/platform/x86/up_board_pinctrl.h
>
--
Andy Shevchenko
Intel Finland Oy
it is only in linux-next, so it cant be more than a few
> weeks old.
It's already quite off topic, so, I would just say that it is still
valid point. Starting from some version of the series (which takes
couple of months?) Bin Gao did improvements.
--
With Best Regards,
Andy Shevchenko
ry.
Good catch!
Acked-by: Andy Shevchenko
P.S. Linus, perhaps this is material for -rc5.
>
> Fixes: 4e80c8f505741cbd ("pinctrl: intel: Add Intel Merrifield pin
> controller support")
> Signed-off-by: Vincent Stehlé
> Cc: Andy Shevchenko
> Cc: Linus Wall
Intel Edison board provides built-in WiFi dongle based on Broadcom BCM43340.
Append the essential data to enable WiFi on Intel Edison.
Signed-off-by: Andy Shevchenko
---
arch/x86/platform/intel-mid/device_libs/Makefile | 2 +
.../intel-mid/device_libs/platform_bcm43xx.c | 95
Intel Merrifield platform provides SD card interface. The interface allows user
to plug SD card to extend storage capacity.
Append the essential data to enable SD card detection on it.
Signed-off-by: Andy Shevchenko
---
arch/x86/platform/intel-mid/device_libs/Makefile | 2 +
.../intel-mid
Of course everything works in case of CONFIG_SDHCI=m, but it's
looks like not a (proper?) solution.
--
Andy Shevchenko
Intel Finland Oy
On Thu, 2016-09-01 at 16:38 +0100, Mark Brown wrote:
> On Thu, Sep 01, 2016 at 05:53:43PM +0300, Andy Shevchenko wrote:
>
> >
> > [ 20.843973] calling sdhci_drv_init+0x0/0x20 @ 1
> > [ 20.843976] sdhci: Secure Digital Host Controller Interface
> > driver
>
> - if (IS_ERR(data->clk) && PTR_ERR(data->clk) == -EPROBE_DEFER)
> {
> + if (IS_ERR(data->pclk) && PTR_ERR(data->pclk) ==
> -EPROBE_DEFER) {
> err = -EPROBE_DEFER;
> goto err_clk;
> }
--
Andy Shevchenko
Intel Finland Oy
On Thu, 2016-08-25 at 15:55 +0300, Andy Shevchenko wrote:
> On Wed, 2016-08-24 at 16:33 +0800, Kefeng Wang wrote:
> >
> > It should check the data->pclk, not data->clk when get apb_pclk.
> >
> > Fixes: c8ed99d4f6a8("serial: 8250_dw: Add support for de
On Thu, Aug 17, 2017 at 6:25 PM, Darren Hart wrote:
> On Sun, Aug 13, 2017 at 03:54:26PM +0300, Andy Shevchenko wrote:
>> On Sat, Aug 12, 2017 at 10:44 AM, Pali Rohár wrote:
>> > This patch series fixes remaining mxm-wmi and asus-wmi drivers to evaluate
>> > W
;s branch fits in with this.
>
> I think Andy is preparing various uuid conversion in it and wanted to
> make sure you don't do any work he already did or which conflicts with
> this work.
Thanks, Christoph, that's correct.
>
> For now please just base it on my uuid-types tree.
Yeah, this is safest option for now.
--
Andy Shevchenko
Intel Finland Oy
m zero that it's must less than
>> the instance_count in _WDG.
>>
>> This patch changes those instance number from one to zero.
>>
>> Cc: Darren Hart
>> Cc: Andy Shevchenko
>> Cc: Pali Rohár
>> Signed-off-by: "Lee, Chun-Yi"
>
&g
Change commit log accordingly.
>
> Use token bit to make the intention more clear.
> Also consider kbd_mode_levels_count and kbd_info.levels, suggested by
> Pali Rohár.
>
> Use XOR to simplify the bitmask comparison, suggested by
> Andy Shevchenko.
>
> drivers/platform/
On Tue, 2017-06-20 at 12:13 -0600, Baicar, Tyler wrote:
> On 6/20/2017 2:47 AM, Andy Shevchenko wrote:
> > On Tue, 2017-06-20 at 10:43 +0200, Christoph Hellwig wrote:
> > >
> Andy,
>
> The patch that was causing compilation failures on your branch was:
>
> 22e31
fdef I would like to hear.
--
With Best Regards,
Andy Shevchenko
first 2 patches
> and esp. the first patch, so that we can get this merged for 4.15, then
> that would be great.
The person comes to my mind is Heikki,
Though I dunno he has time either.
--
With Best Regards,
Andy Shevchenko
Or why
> Dell Latitude E6410 behaves differently?
To be clear, am I waiting for new version?
In any case I mark it as Changes Requested in my patchwork queue.
Feel free to send a new version.
--
With Best Regards,
Andy Shevchenko
*data)
> return 1;
> }
>
> -struct i2c_client *cht_int33fe_find_max17047(void)
> +static struct i2c_client *cht_int33fe_find_max17047(void)
> {
> struct i2c_client *max17047 = NULL;
>
> --
> 2.14.1
>
--
With Best Regards,
Andy Shevchenko
in_tablet_mode = hotkey_gmms_get_tablet_mode(res,
> +
> &has_tablet_mode);
> + if (has_tablet_mode)
> + tp_features.hotkey_tablet =
> TP_HOTKEY_TABLET_USES_GMMS;
> + type = "GMMS";
> + } else if (acpi_evalf(hkey_handle, &res, "MHKG", "qd")) {
> /* For X41t, X60t, X61t Tablets... */
> tp_features.hotkey_tablet = TP_HOTKEY_TABLET_USES_MHKG;
> in_tablet_mode = !!(res & TP_HOTKEY_TABLET_MASK);
> type = "MHKG";
> - } else if (acpi_evalf(ec_handle, &res, "CMMD", "qd")) {
> - /* For X1 Yoga (2016) */
> - tp_features.hotkey_tablet = TP_HOTKEY_TABLET_USES_CMMD;
> - in_tablet_mode = res == TP_EC_CMMD_TABLET_MODE;
> - type = "CMMD";
> }
>
> if (!tp_features.hotkey_tablet)
> --
> 2.13.6
>
--
With Best Regards,
Andy Shevchenko
{
> - pr_info(DRIVER_NAME ": version %s loaded\n", DRIVER_VERSION);
> return platform_driver_register(&telemetry_soc_driver);
> }
>
> --
> 2.7.4
>
--
With Best Regards,
Andy Shevchenko
m_tis_tcg_phy),
> GFP_KERNEL);
> + phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
> if (phy == NULL)
> return -ENOMEM;
>
> diff --git a/drivers/char/tpm/tpm_tis_spi.c
> b/drivers/char/tpm/tpm_tis_spi.c
> index 424ff2fde1f2..7cabb12d0b3a 100644
> --- a/drivers/char/tpm/tpm_tis_spi.c
> +++ b/drivers/char/tpm/tpm_tis_spi.c
> @@ -200,8 +200,7 @@ static int tpm_tis_spi_probe(struct spi_device
> *dev)
> {
> struct tpm_tis_spi_phy *phy;
>
> - phy = devm_kzalloc(&dev->dev, sizeof(struct tpm_tis_spi_phy),
> -GFP_KERNEL);
> + phy = devm_kzalloc(&dev->dev, sizeof(*phy), GFP_KERNEL);
> if (!phy)
> return -ENOMEM;
>
--
Andy Shevchenko
Intel Finland Oy
to the zero day bots that
> catch different sorts of errors, BEFORE code is upstreamed, and
> patches like these, after the fact.
+1.
> After the code has been upstreamed, it is a lot more difficult to
> justify changes like this. It impacts both code that is being
> developed AND backporting bug fixes.
--
Andy Shevchenko
Intel Finland Oy
if (dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_SUSPEND) &&
> + dev_pm_test_driver_flags(dev, DPM_FLAG_AVOID_RPM)) {
Wasn't interface designed to allow something like:
if (dev_pm_test_driver_flags(dev, DPM_FLAG_SMART_SUSPEND |
DPM_FLAG_AVOID_RPM)) {
instead?
Does it make sense to have a separate definition for
DPM_FLAG_SMART_SUSPEND | DPM_FLAG_AVOID_RPM ?
--
Andy Shevchenko
Intel Finland Oy
On Tue, 2017-10-17 at 17:59 +0200, Rafael J. Wysocki wrote:
> On Tuesday, October 17, 2017 5:33:17 PM CEST Andy Shevchenko wrote:
> > On Mon, 2017-10-16 at 03:32 +0200, Rafael J. Wysocki wrote:
> > > If DPM_FLAG_SMART_SUSPEND is not set, DPM_FLAG_AVOID_RPM has no
> > >
le for
> the different machine architectures.
>
> Signed-off-by: Vadim Pasternak
> Acked-by: Andy Shevchenko
> +MELLANOX HARDWARE PLATFORM SUPPORT
> +M: Andy Shevchenko
> +M: Darren Hart
> +M: Vadim Pasternak
> +L: platform-driver-...@vger.kernel.org
> +S
lug_device_en);
> +}
> +
> +static void
> +mlxreg_hotplug_of_device_destroy(struct mlxreg_hotplug_device *data)
> +{
> + of_update_property(data->np, &mlxreg_hotplug_device_dis);
> + of_node_clear_flag(data->np, OF_POPULATED);
> +}
> +#else
> +#endif
--
With Best Regards,
Andy Shevchenko
t; Signed-off-by: Vadim Pasternak
> Acked-by: Andy Shevchenko
> -#define PRIV_ATTR(i) priv->mlxreg_hotplug_attr[i]
> -#define PRIV_DEV_ATTR(i) priv->mlxreg_hotplug_dev_attr[i]
> -static int mlxreg_hotplug_attr_init(struct mlxreg_hotplug_priv_data *priv)
> +static int
> +mlxre
gt; +#define CPER_ARM_ERR_VALID_ADDRESS_SPACE 0x0200
> +#define CPER_ARM_ERR_VALID_MEM_ATTRIBUTES0x0400
> +#define CPER_ARM_ERR_VALID_ACCESS_MODE 0x0800
BIT() is already being used in this file.
> +
> +#define CPER_ARM_ERR_TRANSACTION_SHIFT 16
> +#define CPER
.
Have you talked to Fengguang (0-day LKP)? Have you talked to Arnd (I
think he is related to kernel-ci)?
--
Andy Shevchenko
Intel Finland Oy
.git#for-next
>> appears to currently contain an older state from May 15.
>
> So just not pushed out yet. That's fine, I will hopefully notice when
> it turns up. Just checking that it wasn't forgotten.
No, it wasn't, it it in testing branch, I 'm about to push to for-next.
--
With Best Regards,
Andy Shevchenko
On Fri, May 26, 2017 at 12:07 PM, Stephen Rothwell
wrote:
> Hi Andy,
>
> On Fri, 26 May 2017 12:04:47 +0300 Andy Shevchenko
> wrote:
>>
>> On Fri, May 26, 2017 at 11:35 AM, Stephen Rothwell
>> wrote:
>> > On Fri, 26 May 2017 10:25:36 +0200 Arnd Bergmann
tel(u32 data, u32 offset)
> writel(data, ipcdev.ipc_base + IPC_WRITE_BUFFER + offset);
> }
>
> -static inline u8 ipc_data_readb(u32 offset)
> +static inline u8 __maybe_unused ipc_data_readb(u32 offset)
> {
> return readb(ipcdev.ipc_base + IPC_READ_BUFFER + offset);
> }
> --
> 2.13.0.219.gdb65acc882-goog
>
--
With Best Regards,
Andy Shevchenko
e latter is the option.
--
With Best Regards,
Andy Shevchenko
+
> x86_init.resources.probe_roms();
>
> /* after parse_early_param, so could debug it */
--
With Best Regards,
Andy Shevchenko
On Sat, May 27, 2017 at 8:15 AM, Darren Hart wrote:
> From: Andy Lutomirski
>
> The hotkey table is 0xb2, add a comment for clarity.
>
Reviewed-by: Andy Shevchenko
> Suggested-by: Darren Hart
> Signed-off-by: Andy Lutomirski
> Cc: Matthew Garrett
> Cc: "Pali
On Sat, May 27, 2017 at 8:16 AM, Darren Hart wrote:
> From: Andy Lutomirski
>
> This is based on Mario's explanation and observation of my laptop.
>
Reviewed-by: Andy Shevchenko
> Suggested-by: "Pali Rohár"
> Signed-off-by: Andy Lutomirski
> Cc: Mari
P?
>
> Yeah, empty "unregister_pm_notifier" in !CONFIG_PM_SLEEP case sounds
> like a good idea.
I like the idea, though I would let Rafael to speak up.
--
With Best Regards,
Andy Shevchenko
re in this file because there is no significant code in the
> base file and the two guys are fully credited in the i2c-mux file and b)
> add my own copyright for the period of me being the maintainer.
FWIW: here is my
Reviewed-by: Andy Shevchenko
for entire series _except_ this change. I'
d: 0x%02X\n", g->notify_id);
> + else
> + pr_info("\tobject_id: %c%c\n", g->object_id[0],
> g->object_id[1]);
If this can still contain non-printable characters the %*pE can help instead.
--
With Best Regards,
Andy Shevchenko
VICE(PCI_VENDOR_ID_STMICRO, PCI_DEVICE_ID_STMICRO_MAC,
> + stmmac_pci_info),
> + STMMAC_DEVICE(PCI_VENDOR_ID_INTEL, STMMAC_QUARK_ID, quark_pci_info),
--
With Best Regards,
Andy Shevchenko
On Sat, May 27, 2017 at 4:13 PM, Andy Shevchenko
wrote:
> On Fri, May 26, 2017 at 7:07 PM, Jan Kiszka wrote:
>> Make stmmac_default_data compatible with stmmac_pci_info.setup and use
>> an info structure for all devices. This allows to make the probing more
>> regular.
&g
)
return ret;
/*
* Comment goes here, I suppose.
*/
ret = 1;
> + }
--
With Best Regards,
Andy Shevchenko
mmac_dmi_data,
Can't be slightly better
.driver_data = &galileo_stmmac_dmi_data,
?
--
With Best Regards,
Andy Shevchenko
On Sat, May 27, 2017 at 4:17 PM, Pali Rohár wrote:
> On Saturday 27 May 2017 15:07:09 Andy Shevchenko wrote:
>> On Sat, May 27, 2017 at 2:51 PM, Pali Rohár
>> wrote:
>> > Remove
>> > also reserved member as it does not have any defined meaning or
>> > t
tend this and
effectively revert this change.
So, my vote is to leave it as is for now.
--
With Best Regards,
Andy Shevchenko
On Fri, May 26, 2017 at 7:02 PM, Jan Kiszka wrote:
> Commtech adapters need the MPIOs for internal purposes, and the
> gpio-exar driver already refused to pick them up. But there is actually
> no point in even creating the underlying platform device.
FWIW:
Reviewed-by: Andy Shevchenko
on exit. But this won't help anyway as the core clears
> drvdata after the driver left.
>
> Set the platform device parent instead.
Now this one looks much better than first efforts.
Reviewed-by: Andy Shevchenko
>
> Signed-off-by: Jan Kiszka
> ---
> drivers/gpio/gpio-e
mpanion is a right thing to do (like it's done in other similar cases)
Reviewed-by: Andy Shevchenko
> Signed-off-by: Jan Kiszka
> ---
> drivers/gpio/gpio-exar.c| 2 +-
> drivers/tty/serial/8250/8250_exar.c | 2 ++
> 2 files changed, 3 insertions(+), 1 deletion(
l lines you touched here.
--
With Best Regards,
Andy Shevchenko
gt; + device_property_read_u32(&pdev->dev, "npins", &npins) < 0)
"ngpios"
--
With Best Regards,
Andy Shevchenko
ret = platform->register_gpio(pcidev, port);
> }
Can't you move at least some of this to the patch where you move the check?
--
With Best Regards,
Andy Shevchenko
rom colleague of mine couple of years ago, they (their
team) moved to 100 characters in Python scripts because of somehow
stupid recommendations from last century.
--
With Best Regards,
Andy Shevchenko
On Fri, May 26, 2017 at 4:17 PM, Jan Kiszka wrote:
> See patches for details.
>
FWIW:
Reviewed-by: Andy Shevchenko
P.S. Of course it would be also nice to convert to GPIO descriptors,
though it's not related to this series.
> Jan Kiszka (2):
> leds: trigger: gpio: Refres
_MODULE;
> + priv->rcdev.ops = &basic_reset_ops;
> + priv->rcdev.of_node = pdev->dev.of_node;
> + priv->rcdev.nr_resets = 32;
> +
> + return reset_controller_register(&priv->rcdev);
> +}
> +
> +static const struct of_device_id basic_reset_dt_match[] = {
> + { .compatible = "reset-basic" },
> + { },
> +};
> +
> +static struct platform_driver basic_reset_driver = {
> + .probe = basic_reset_probe,
> + .driver = {
> + .name = "basic-reset",
> + .of_match_table = basic_reset_dt_match,
> + },
> +};
> +builtin_platform_driver(basic_reset_driver);
> --
> 2.11.0
>
--
With Best Regards,
Andy Shevchenko
db(bar0 + 1)
> - readl(bar0)
It depends.
--
With Best Regards,
Andy Shevchenko
return;
> +
> if (ctl->rx)
> ring_free(ctl->rx);
> if (ctl->tx)
> --
> 2.11.0
>
--
With Best Regards,
Andy Shevchenko
x;
> + }
It might make sense to add some comment as we discussed earlier
(privately) about (non-)compatibiliness with UUID by spec and why 0xff
are used.
--
With Best Regards,
Andy Shevchenko
rn value is currently ignored. Evaluate it and abort parsing on
> error.
>
> Change tb_drom_parse_entries() to accommodate for parsing of other entry
> types than TB_DROM_ENTRY_PORT.
>
FWIW:
Reviewed-by: Andy Shevchenko
> Signed-off-by: Lukas Wunner
> Signed-off-by: Mik
e = parse_name(entry->data,
> +header->len - sizeof(*header));
> + if (!sw->device_name)
> + return -ENOMEM;
> + break;
> + }
> +
> + return 0;
> +}
--
With Best Regards,
Andy Shevchenko
On Sat, May 27, 2017 at 6:57 PM, Andy Shevchenko
wrote:
> On Fri, May 26, 2017 at 7:09 PM, Mika Westerberg
> wrote:
>> The device DROM contains name of the vendor and device among other
>> things. Extract this information and expose it to the userspace via two
>> new
:
> + case PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C:
> + case PCI_DEVICE_ID_INTEL_PORT_RIDGE:
> + case PCI_DEVICE_ID_INTEL_REDWOOD_RIDGE_2C_BRIDGE:
> + case PCI_DEVICE_ID_INTEL_REDWOOD_RIDGE_4C_BRIDGE:
> + return 1;
Other than that
FWIW:
Reviewed-by: Andy Shevchenko
--
With Best Regards,
Andy Shevchenko
}
Just to be sure I didn't miss anything.
Can't we just map buffer into DMA capable address space instead of memcpy()'ing?
--
With Best Regards,
Andy Shevchenko
On Sat, May 27, 2017 at 2:59 AM, Darren Hart wrote:
> From: Andy Lutomirski
>
> Currently they return -1 on error, which will confuse callers if
> they try to interpret it as a normal negative error code.
>
Obviously makes sense!
Reviewed-by: Andy Shevchenko
> Signed-off-b
evice, but that we
> are intentionally ignoring it.
>
Pali made a good point.
Otherwise, FWIW:
Reviewed-by: Andy Shevchenko
> Signed-off-by: Andy Lutomirski
> [dvhart: New commit message and minor comment wording fixes]
> Cc: Mario Limonciello
> Cc: "Pali Rohár&
64 imrx;
> u64 imrd;
> u64 ipcx;
> u64 ipcd;
--
With Best Regards,
Andy Shevchenko
kup.c
> +++ b/drivers/gpio/gpio-mockup.c
> @@ -29,8 +29,8 @@
> #defineGPIO_MOCKUP_MAX_GC 10
>
> enum {
> - DIR_IN = 0,
> - DIR_OUT,
> + DIR_OUT = 0,
> + DIR_IN = 1,
> };
>
> /*
> --
> 2.9.3
>
--
With Best Regards,
Andy Shevchenko
701 - 800 of 10895 matches
Mail list logo
