Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1443876 > unrolled thread

linux-next: manual merge of the pm tree with the i2c tree

Started byStephen Rothwell <sfr@canb.auug.org.au>
First post2016-07-15 04:20 +0200
Last post2016-07-25 14:10 +0200
Articles 11 — 4 participants

Back to article view | Back to linux.kernel


Contents

  linux-next: manual merge of the pm tree with the i2c tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-07-15 04:20 +0200
    Re: linux-next: manual merge of the pm tree with the i2c tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-07-15 04:30 +0200
      Re: linux-next: manual merge of the pm tree with the i2c tree "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-07-15 14:20 +0200
        Re: linux-next: manual merge of the pm tree with the i2c tree Wolfram Sang <wsa@the-dreams.de> - 2016-07-15 14:40 +0200
          Re: linux-next: manual merge of the pm tree with the i2c tree "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-07-15 14:40 +0200
          Re: linux-next: manual merge of the pm tree with the i2c tree "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-07-15 15:00 +0200
            Re: linux-next: manual merge of the pm tree with the i2c tree Wolfram Sang <wsa@the-dreams.de> - 2016-07-17 20:20 +0200
              Re: linux-next: manual merge of the pm tree with the i2c tree "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-07-19 04:40 +0200
                Re: linux-next: manual merge of the pm tree with the i2c tree Wolfram Sang <wsa@the-dreams.de> - 2016-07-19 05:50 +0200
                  Re: linux-next: manual merge of the pm tree with the i2c tree "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-07-19 15:00 +0200
                  Re: linux-next: manual merge of the pm tree with the i2c tree Andy Shevchenko <andy.shevchenko@gmail.com> - 2016-07-25 14:10 +0200

#1443876 — linux-next: manual merge of the pm tree with the i2c tree

FromStephen Rothwell <sfr@canb.auug.org.au>
Date2016-07-15 04:20 +0200
Subjectlinux-next: manual merge of the pm tree with the i2c tree
Message-ID<rV0Tn-ZV-1@gated-at.bofh.it>
Hi Rafael,

Today's linux-next merge of the pm tree got a conflict in:

  drivers/i2c/i2c-core.c

between commit:

  a7003b65801e ("i2c: core: Cleanup I2C ACPI namespace")
  55d38d060e99 ("i2c: core: Add function for finding the bus speed from ACPI")

from the i2c tree and commit:

  525e6fabeae2 ("i2c / ACPI: add support for ACPI reconfigure notifications")

from the pm tree.

I fixed it up (I think, but it needs more work - see below) and can
carry 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.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/i2c/i2c-core.c
index 77ce28f2dd4c,74e5aeaf84f9..000000000000
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@@ -103,20 -101,17 +103,19 @@@ struct gsb_buffer 
  	};
  } __packed;
  
 -struct acpi_i2c_lookup {
 +struct i2c_acpi_lookup {
  	struct i2c_board_info *info;
 +	struct i2c_adapter *adapter; /* set only when registering slaves */
  	acpi_handle adapter_handle;
  	acpi_handle device_handle;
 +	u32 min_speed;
  };
  
 -static int acpi_i2c_fill_info(struct acpi_resource *ares, void *data)
 +static int i2c_acpi_find_resource(struct acpi_resource *ares, void *data)
  {
 -	struct acpi_i2c_lookup *lookup = data;
 +	struct i2c_acpi_lookup *lookup = data;
  	struct i2c_board_info *info = lookup->info;
  	struct acpi_resource_i2c_serialbus *sb;
- 	acpi_handle adapter_handle;
  	acpi_status status;
  
  	if (info->addr || ares->type != ACPI_RESOURCE_TYPE_SERIAL_BUS)
@@@ -126,97 -121,110 +125,181 @@@
  	if (sb->type != ACPI_RESOURCE_SERIAL_TYPE_I2C)
  		return 1;
  
- 	/*
- 	 * Extract the ResourceSource and make sure that the handle matches
- 	 * with the I2C adapter handle.
- 	 */
  	status = acpi_get_handle(lookup->device_handle,
  				 sb->resource_source.string_ptr,
- 				 &adapter_handle);
- 	if (ACPI_SUCCESS(status) && adapter_handle == lookup->adapter_handle) {
- 		info->addr = sb->slave_address;
- 		if (sb->access_mode == ACPI_I2C_10BIT_MODE)
- 			info->flags |= I2C_CLIENT_TEN;
- 		/* Save speed of the slowest device */
- 		if (sb->connection_speed < lookup->min_speed)
- 			lookup->min_speed = sb->connection_speed;
- 	}
+ 				 &lookup->adapter_handle);
+ 	if (!ACPI_SUCCESS(status))
+ 		return 1;
+ 
+ 	info->addr = sb->slave_address;
+ 	if (sb->access_mode == ACPI_I2C_10BIT_MODE)
+ 		info->flags |= I2C_CLIENT_TEN;
++	/* Save speed of the slowest device */
++	if (sb->connection_speed < lookup->min_speed)
++		lookup->min_speed = sb->connection_speed;
  
  	return 1;
  }
  
 -static int acpi_i2c_get_info(struct acpi_device *adev,
 +static acpi_status i2c_acpi_slave_lookup(acpi_handle handle, u32 level,
 +					 void *data, void **return_value)
 +{
 +	struct i2c_acpi_lookup *lookup = data;
 +	struct i2c_adapter *adapter = lookup->adapter;
 +	struct list_head resource_list;
 +	struct resource_entry *entry;
 +	struct i2c_board_info info;
 +	struct acpi_device *adev;
 +	int ret;
 +
 +	if (acpi_bus_get_device(handle, &adev))
 +		return AE_OK;
 +	if (acpi_bus_get_status(adev) || !adev->status.present)
 +		return AE_OK;
 +
 +	memset(&info, 0, sizeof(info));
 +	info.fwnode = acpi_fwnode_handle(adev);
 +
 +	lookup->device_handle = handle;
 +	lookup->info = &info;
 +
 +	/*
 +	 * Look up for I2cSerialBus resource with ResourceSource that
 +	 * matches with this adapter.
 +	 */
 +	INIT_LIST_HEAD(&resource_list);
 +	ret = acpi_dev_get_resources(adev, &resource_list,
 +				     i2c_acpi_find_resource, lookup);
 +	acpi_dev_free_resource_list(&resource_list);
 +
 +	if (ret < 0 || !info.addr || !lookup->adapter)
 +		return AE_OK;
 +
 +	/* Then fill IRQ number if any */
 +	ret = acpi_dev_get_resources(adev, &resource_list, NULL, NULL);
 +	if (ret < 0)
 +		return AE_OK;
 +
 +	resource_list_for_each_entry(entry, &resource_list) {
 +		if (resource_type(entry->res) == IORESOURCE_IRQ) {
 +			info.irq = entry->res->start;
 +			break;
 +		}
 +	}
 +
 +	acpi_dev_free_resource_list(&resource_list);
 +
 +	adev->power.flags.ignore_parent = true;
 +	strlcpy(info.type, dev_name(&adev->dev), sizeof(info.type));
 +	if (!i2c_new_device(adapter, &info)) {
 +		adev->power.flags.ignore_parent = false;
 +		dev_err(&adapter->dev,
 +			"failed to add I2C device %s from ACPI\n",
 +			dev_name(&adev->dev));
 +	}
 +
 +	return AE_OK;
 +}
 +
++static int i2c_acpi_get_info(struct acpi_device *adev,
+ 			     struct i2c_board_info *info,
+ 			     acpi_handle *adapter_handle)
+ {
+ 	struct list_head resource_list;
+ 	struct resource_entry *entry;
 -	struct acpi_i2c_lookup lookup;
++	struct i2c_acpi_lookup lookup;
+ 	int ret;
+ 
+ 	if (acpi_bus_get_status(adev) || !adev->status.present ||
+ 	    acpi_device_enumerated(adev))
+ 		return -EINVAL;
+ 
+ 	memset(info, 0, sizeof(*info));
+ 	info->fwnode = acpi_fwnode_handle(adev);
+ 
+ 	memset(&lookup, 0, sizeof(lookup));
+ 	lookup.device_handle = acpi_device_handle(adev);
+ 	lookup.info = info;
+ 
+ 	/* Look up for I2cSerialBus resource */
+ 	INIT_LIST_HEAD(&resource_list);
+ 	ret = acpi_dev_get_resources(adev, &resource_list,
 -				     acpi_i2c_fill_info, &lookup);
++				     i2c_acpi_find_resource, &lookup);
+ 	acpi_dev_free_resource_list(&resource_list);
+ 
+ 	if (ret < 0 || !info->addr)
+ 		return -EINVAL;
+ 
+ 	*adapter_handle = lookup.adapter_handle;
+ 
+ 	/* Then fill IRQ number if any */
+ 	ret = acpi_dev_get_resources(adev, &resource_list, NULL, NULL);
+ 	if (ret < 0)
+ 		return -EINVAL;
+ 
+ 	resource_list_for_each_entry(entry, &resource_list) {
+ 		if (resource_type(entry->res) == IORESOURCE_IRQ) {
+ 			info->irq = entry->res->start;
+ 			break;
+ 		}
+ 	}
+ 
+ 	acpi_dev_free_resource_list(&resource_list);
+ 
+ 	strlcpy(info->type, dev_name(&adev->dev), sizeof(info->type));
+ 
+ 	return 0;
+ }
+ 
 -static void acpi_i2c_register_device(struct i2c_adapter *adapter,
++static void i2c_acpi_register_device(struct i2c_adapter *adapter,
+ 				     struct acpi_device *adev,
+ 				     struct i2c_board_info *info)
+ {
+ 	adev->power.flags.ignore_parent = true;
+ 	acpi_device_set_enumerated(adev);
+ 
+ 	if (!i2c_new_device(adapter, info)) {
+ 		adev->power.flags.ignore_parent = false;
+ 		dev_err(&adapter->dev,
+ 			"failed to add I2C device %s from ACPI\n",
+ 			dev_name(&adev->dev));
+ 	}
+ }
+ 
 -static acpi_status acpi_i2c_add_device(acpi_handle handle, u32 level,
++static acpi_status i2c_acpi_add_device(acpi_handle handle, u32 level,
+ 				       void *data, void **return_value)
+ {
+ 	struct i2c_adapter *adapter = data;
+ 	struct acpi_device *adev;
+ 	acpi_handle adapter_handle;
+ 	struct i2c_board_info info;
+ 
+ 	if (acpi_bus_get_device(handle, &adev))
+ 		return AE_OK;
+ 
 -	if (acpi_i2c_get_info(adev, &info, &adapter_handle))
++	if (i2c_acpi_get_info(adev, &info, &adapter_handle))
+ 		return AE_OK;
+ 
+ 	if (adapter_handle != ACPI_HANDLE(&adapter->dev))
+ 		return AE_OK;
+ 
 -	acpi_i2c_register_device(adapter, adev, &info);
++	i2c_acpi_register_device(adapter, adev, &info);
+ 
+ 	return AE_OK;
+ }
+ 
 -#define ACPI_I2C_MAX_SCAN_DEPTH 32
 +#define I2C_ACPI_MAX_SCAN_DEPTH 32
 +
 +static acpi_status i2c_acpi_walk(struct i2c_acpi_lookup *lookup)
 +{
 +	return acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
 +				   I2C_ACPI_MAX_SCAN_DEPTH,
 +				   i2c_acpi_slave_lookup, NULL,
 +				   lookup, NULL);
 +}
  
  /**
 - * acpi_i2c_register_devices - enumerate I2C slave devices behind adapter
 + * i2c_acpi_register_devices - enumerate I2C slave devices behind adapter
   * @adap: pointer to adapter
   *
   * Enumerate all I2C slave devices behind this adapter by walking the ACPI
@@@ -240,39 -246,80 +323,111 @@@ static void i2c_acpi_register_devices(s
  		dev_warn(&adap->dev, "failed to enumerate I2C slaves\n");
  }
  
 -static int acpi_i2c_match_adapter(struct device *dev, void *data)
 +/**
 + * i2c_acpi_find_bus_speed - find I2C bus speed from ACPI
 + * @dev: The device owning the bus
 + *
 + * Find the I2C bus speed by walking the ACPI namespace for all I2C slaves
 + * devices connected to this bus and use the speed of slowest device.
 + *
 + * Returns the speed in Hz or zero
 + */
 +u32 i2c_acpi_find_bus_speed(struct device *dev)
 +{
 +	struct i2c_acpi_lookup lookup;
 +	acpi_status status;
 +
 +	if (!has_acpi_companion(dev))
 +		return 0;
 +
 +	memset(&lookup, 0, sizeof(lookup));
 +	lookup.adapter_handle = ACPI_HANDLE(dev);
 +	lookup.min_speed = UINT_MAX;
 +
 +	status = i2c_acpi_walk(&lookup);
 +	if (ACPI_FAILURE(status)) {
 +		dev_warn(dev, "unable to find I2C bus speed from ACPI\n");
 +		return 0;
 +	}
 +
 +	return lookup.min_speed != UINT_MAX ? lookup.min_speed : 0;
 +}
 +EXPORT_SYMBOL_GPL(i2c_acpi_find_bus_speed);
 +
++static int i2c_acpi_match_adapter(struct device *dev, void *data)
+ {
+ 	struct i2c_adapter *adapter = i2c_verify_adapter(dev);
+ 
+ 	if (!adapter)
+ 		return 0;
+ 
+ 	return ACPI_HANDLE(dev) == (acpi_handle)data;
+ }
+ 
 -static int acpi_i2c_match_device(struct device *dev, void *data)
++static int i2c_acpi_match_device(struct device *dev, void *data)
+ {
+ 	return ACPI_COMPANION(dev) == data;
+ }
+ 
 -static struct i2c_adapter *acpi_i2c_find_adapter_by_handle(acpi_handle handle)
++static struct i2c_adapter *i2c_acpi_find_adapter_by_handle(acpi_handle handle)
+ {
+ 	struct device *dev;
+ 
+ 	dev = bus_find_device(&i2c_bus_type, NULL, handle,
 -			      acpi_i2c_match_adapter);
++			      i2c_acpi_match_adapter);
+ 	return dev ? i2c_verify_adapter(dev) : NULL;
+ }
+ 
 -static struct i2c_client *acpi_i2c_find_client_by_adev(struct acpi_device *adev)
++static struct i2c_client *i2c_acpi_find_client_by_adev(struct acpi_device *adev)
+ {
+ 	struct device *dev;
+ 
 -	dev = bus_find_device(&i2c_bus_type, NULL, adev, acpi_i2c_match_device);
++	dev = bus_find_device(&i2c_bus_type, NULL, adev, i2c_acpi_match_device);
+ 	return dev ? i2c_verify_client(dev) : NULL;
+ }
+ 
 -static int acpi_i2c_notify(struct notifier_block *nb, unsigned long value,
++static int i2c_acpi_notify(struct notifier_block *nb, unsigned long value,
+ 			   void *arg)
+ {
+ 	struct acpi_device *adev = arg;
+ 	struct i2c_board_info info;
+ 	acpi_handle adapter_handle;
+ 	struct i2c_adapter *adapter;
+ 	struct i2c_client *client;
+ 
+ 	switch (value) {
+ 	case ACPI_RECONFIG_DEVICE_ADD:
 -		if (acpi_i2c_get_info(adev, &info, &adapter_handle))
++		if (i2c_acpi_get_info(adev, &info, &adapter_handle))
+ 			break;
+ 
 -		adapter = acpi_i2c_find_adapter_by_handle(adapter_handle);
++		adapter = i2c_acpi_find_adapter_by_handle(adapter_handle);
+ 		if (!adapter)
+ 			break;
+ 
 -		acpi_i2c_register_device(adapter, adev, &info);
++		i2c_acpi_register_device(adapter, adev, &info);
+ 		break;
+ 	case ACPI_RECONFIG_DEVICE_REMOVE:
+ 		if (!acpi_device_enumerated(adev))
+ 			break;
+ 
 -		client = acpi_i2c_find_client_by_adev(adev);
++		client = i2c_acpi_find_client_by_adev(adev);
+ 		if (!client)
+ 			break;
+ 
+ 		i2c_unregister_device(client);
+ 		put_device(&client->dev);
+ 		break;
+ 	}
+ 
+ 	return NOTIFY_OK;
+ }
+ 
+ static struct notifier_block i2c_acpi_notifier = {
 -	.notifier_call = acpi_i2c_notify,
++	.notifier_call = i2c_acpi_notify,
+ };
  #else /* CONFIG_ACPI */
 -static inline void acpi_i2c_register_devices(struct i2c_adapter *adap) { }
 +static inline void i2c_acpi_register_devices(struct i2c_adapter *adap) { }
+ extern struct notifier_block i2c_acpi_notifier;
  #endif /* CONFIG_ACPI */
  
  #ifdef CONFIG_ACPI_I2C_OPREGION

[toc] | [next] | [standalone]


#1443883

FromStephen Rothwell <sfr@canb.auug.org.au>
Date2016-07-15 04:30 +0200
Message-ID<rV133-14j-5@gated-at.bofh.it>
In reply to#1443876
Hi all,

On Fri, 15 Jul 2016 12:17:23 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> I fixed it up (I think, but it needs more work - see below) and can

For a start, it generates this warning, now:

drivers/i2c/i2c-core.c:269:20: warning: 'i2c_acpi_add_device' defined but not used [-Wunused-function]
static acpi_status i2c_acpi_add_device(acpi_handle handle, u32 level,
                   ^

-- 
Cheers,
Stephen Rothwell

[toc] | [prev] | [next] | [standalone]


#1444247

From"Rafael J. Wysocki" <rjw@rjwysocki.net>
Date2016-07-15 14:20 +0200
Message-ID<rVag2-6Nq-19@gated-at.bofh.it>
In reply to#1443883
On Friday, July 15, 2016 12:28:53 PM Stephen Rothwell wrote:
> Hi all,
> 
> On Fri, 15 Jul 2016 12:17:23 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > I fixed it up (I think, but it needs more work - see below) and can
> 
> For a start, it generates this warning, now:
> 
> drivers/i2c/i2c-core.c:269:20: warning: 'i2c_acpi_add_device' defined but not used [-Wunused-function]
> static acpi_status i2c_acpi_add_device(acpi_handle handle, u32 level,
>                    ^

OK, thanks for the heads-up.

Wolfram, what about if I exposed my "acpi-tables" branch for you to pull?

You could resolve this in your tree then.

Thanks,
Rafael

[toc] | [prev] | [next] | [standalone]


#1444259

FromWolfram Sang <wsa@the-dreams.de>
Date2016-07-15 14:40 +0200
Message-ID<rVazo-6Uc-7@gated-at.bofh.it>
In reply to#1444247

[Multipart message — attachments visible in raw view] — view raw

On Fri, Jul 15, 2016 at 02:19:28PM +0200, Rafael J. Wysocki wrote:
> On Friday, July 15, 2016 12:28:53 PM Stephen Rothwell wrote:
> > Hi all,
> > 
> > On Fri, 15 Jul 2016 12:17:23 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > I fixed it up (I think, but it needs more work - see below) and can
> > 
> > For a start, it generates this warning, now:
> > 
> > drivers/i2c/i2c-core.c:269:20: warning: 'i2c_acpi_add_device' defined but not used [-Wunused-function]
> > static acpi_status i2c_acpi_add_device(acpi_handle handle, u32 level,
> >                    ^
> 
> OK, thanks for the heads-up.

Yes, thanks!

> 
> Wolfram, what about if I exposed my "acpi-tables" branch for you to pull?
> 
> You could resolve this in your tree then.

I can pull it in, sure. For the fixup, I'd like a commitment from one of
the ACPI experts (Jarkko, Mika, Andy), though. Otherwise I'd need to
revert given that we are quite late in the cycle already.

[toc] | [prev] | [next] | [standalone]


#1444262

From"Rafael J. Wysocki" <rjw@rjwysocki.net>
Date2016-07-15 14:40 +0200
Message-ID<rVazo-6Uc-23@gated-at.bofh.it>
In reply to#1444259

[Multipart message — attachments visible in raw view] — view raw

On Friday, July 15, 2016 09:32:54 PM Wolfram Sang wrote:
> On Fri, Jul 15, 2016 at 02:19:28PM +0200, Rafael J. Wysocki wrote:
> > On Friday, July 15, 2016 12:28:53 PM Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > On Fri, 15 Jul 2016 12:17:23 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > >
> > > > I fixed it up (I think, but it needs more work - see below) and can
> > > 
> > > For a start, it generates this warning, now:
> > > 
> > > drivers/i2c/i2c-core.c:269:20: warning: 'i2c_acpi_add_device' defined but not used [-Wunused-function]
> > > static acpi_status i2c_acpi_add_device(acpi_handle handle, u32 level,
> > >                    ^
> > 
> > OK, thanks for the heads-up.
> 
> Yes, thanks!
> 
> > 
> > Wolfram, what about if I exposed my "acpi-tables" branch for you to pull?
> > 
> > You could resolve this in your tree then.
> 
> I can pull it in, sure. For the fixup, I'd like a commitment from one of
> the ACPI experts (Jarkko, Mika, Andy), though. Otherwise I'd need to
> revert given that we are quite late in the cycle already.

Well, I can help with that too, I suppose.

Thanks,
Rafael

[toc] | [prev] | [next] | [standalone]


#1444274

From"Rafael J. Wysocki" <rjw@rjwysocki.net>
Date2016-07-15 15:00 +0200
Message-ID<rVaSK-70X-11@gated-at.bofh.it>
In reply to#1444259

[Multipart message — attachments visible in raw view] — view raw

On Friday, July 15, 2016 09:32:54 PM Wolfram Sang wrote:
> On Fri, Jul 15, 2016 at 02:19:28PM +0200, Rafael J. Wysocki wrote:
> > On Friday, July 15, 2016 12:28:53 PM Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > On Fri, 15 Jul 2016 12:17:23 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > >
> > > > I fixed it up (I think, but it needs more work - see below) and can
> > > 
> > > For a start, it generates this warning, now:
> > > 
> > > drivers/i2c/i2c-core.c:269:20: warning: 'i2c_acpi_add_device' defined but not used [-Wunused-function]
> > > static acpi_status i2c_acpi_add_device(acpi_handle handle, u32 level,
> > >                    ^
> > 
> > OK, thanks for the heads-up.
> 
> Yes, thanks!
> 
> > 
> > Wolfram, what about if I exposed my "acpi-tables" branch for you to pull?
> > 
> > You could resolve this in your tree then.
> 
> I can pull it in, sure. For the fixup, I'd like a commitment from one of
> the ACPI experts (Jarkko, Mika, Andy), though. Otherwise I'd need to
> revert given that we are quite late in the cycle already.

The branch is here:

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git acpi-tables

The top-most commit is:

fafe5306f201 ACPI: Rename configfs.c to acpi_configfs.c to prevent link error

I won't rebase this branch going forward, so it is safe to pull.

Please let me know how I can help with the conflict resolution.

Thanks,
Rafael

[toc] | [prev] | [next] | [standalone]


#1445070

FromWolfram Sang <wsa@the-dreams.de>
Date2016-07-17 20:20 +0200
Message-ID<rVYPv-46h-5@gated-at.bofh.it>
In reply to#1444274

[Multipart message — attachments visible in raw view] — view raw

> > > > > I fixed it up (I think, but it needs more work - see below) and can
> > > > 
> > > > For a start, it generates this warning, now:
> > > > 
> > > > drivers/i2c/i2c-core.c:269:20: warning: 'i2c_acpi_add_device' defined but not used [-Wunused-function]
> > > > static acpi_status i2c_acpi_add_device(acpi_handle handle, u32 level,
> > > >                    ^
> > > 
> > > OK, thanks for the heads-up.
> > 
> > Yes, thanks!
> > 
> > > 
> > > Wolfram, what about if I exposed my "acpi-tables" branch for you to pull?
> > > 
> > > You could resolve this in your tree then.
> > 
> > I can pull it in, sure. For the fixup, I'd like a commitment from one of
> > the ACPI experts (Jarkko, Mika, Andy), though. Otherwise I'd need to
> > revert given that we are quite late in the cycle already.
> 
> The branch is here:
> 
>  git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git acpi-tables
> 
> The top-most commit is:
> 
> fafe5306f201 ACPI: Rename configfs.c to acpi_configfs.c to prevent link error
> 
> I won't rebase this branch going forward, so it is safe to pull.
> 
> Please let me know how I can help with the conflict resolution.

Well, not knowing much about ACPI, I just need the conflict resolution
for my latest i2c/for-next and your above branch. If you want to do it,
fine with me. But maybe Jarkko will be back to office on Monday, too.

[toc] | [prev] | [next] | [standalone]


#1445994

From"Rafael J. Wysocki" <rjw@rjwysocki.net>
Date2016-07-19 04:40 +0200
Message-ID<rWt6W-6qm-11@gated-at.bofh.it>
In reply to#1445070

[Multipart message — attachments visible in raw view] — view raw

On Sunday, July 17, 2016 08:14:48 PM Wolfram Sang wrote:
> 
> > > > > > I fixed it up (I think, but it needs more work - see below) and can
> > > > > 
> > > > > For a start, it generates this warning, now:
> > > > > 
> > > > > drivers/i2c/i2c-core.c:269:20: warning: 'i2c_acpi_add_device' defined but not used [-Wunused-function]
> > > > > static acpi_status i2c_acpi_add_device(acpi_handle handle, u32 level,
> > > > >                    ^
> > > > 
> > > > OK, thanks for the heads-up.
> > > 
> > > Yes, thanks!
> > > 
> > > > 
> > > > Wolfram, what about if I exposed my "acpi-tables" branch for you to pull?
> > > > 
> > > > You could resolve this in your tree then.
> > > 
> > > I can pull it in, sure. For the fixup, I'd like a commitment from one of
> > > the ACPI experts (Jarkko, Mika, Andy), though. Otherwise I'd need to
> > > revert given that we are quite late in the cycle already.
> > 
> > The branch is here:
> > 
> >  git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git acpi-tables
> > 
> > The top-most commit is:
> > 
> > fafe5306f201 ACPI: Rename configfs.c to acpi_configfs.c to prevent link error
> > 
> > I won't rebase this branch going forward, so it is safe to pull.
> > 
> > Please let me know how I can help with the conflict resolution.
> 
> Well, not knowing much about ACPI, I just need the conflict resolution
> for my latest i2c/for-next and your above branch. If you want to do it,
> fine with me. But maybe Jarkko will be back to office on Monday, too.

Unfortunately, I don't see how these branches can be merged in a sensible
way without adding too much new code into the merge itself.

Something needs to be dropped and then rebased and applied again.

Thanks,
Rafael

[toc] | [prev] | [next] | [standalone]


#1446006

FromWolfram Sang <wsa@the-dreams.de>
Date2016-07-19 05:50 +0200
Message-ID<rWucF-76K-1@gated-at.bofh.it>
In reply to#1445994

[Multipart message — attachments visible in raw view] — view raw

> > Well, not knowing much about ACPI, I just need the conflict resolution
> > for my latest i2c/for-next and your above branch. If you want to do it,
> > fine with me. But maybe Jarkko will be back to office on Monday, too.
> 
> Unfortunately, I don't see how these branches can be merged in a sensible
> way without adding too much new code into the merge itself.
> 
> Something needs to be dropped and then rebased and applied again.

Okay, I'll drop the I2C parts. Next to the core parts which I will drop,
there was also a driver patch making use of the core changes for which I
requested some updates. Since those did not happen yet (Jarkko on
holiday?), the core patches alone are not important anyhow.

Thanks for looking into it!

   Wolfram

[toc] | [prev] | [next] | [standalone]


#1446415

From"Rafael J. Wysocki" <rjw@rjwysocki.net>
Date2016-07-19 15:00 +0200
Message-ID<rWCN0-47Q-7@gated-at.bofh.it>
In reply to#1446006

[Multipart message — attachments visible in raw view] — view raw

On Tuesday, July 19, 2016 05:48:07 AM Wolfram Sang wrote:
> 
> > > Well, not knowing much about ACPI, I just need the conflict resolution
> > > for my latest i2c/for-next and your above branch. If you want to do it,
> > > fine with me. But maybe Jarkko will be back to office on Monday, too.
> > 
> > Unfortunately, I don't see how these branches can be merged in a sensible
> > way without adding too much new code into the merge itself.
> > 
> > Something needs to be dropped and then rebased and applied again.
> 
> Okay, I'll drop the I2C parts. Next to the core parts which I will drop,
> there was also a driver patch making use of the core changes for which I
> requested some updates. Since those did not happen yet (Jarkko on
> holiday?), the core patches alone are not important anyhow.

Thanks a lot!

> Thanks for looking into it!

No problem.

Thanks,
Rafael

[toc] | [prev] | [next] | [standalone]


#1449439

FromAndy Shevchenko <andy.shevchenko@gmail.com>
Date2016-07-25 14:10 +0200
Message-ID<rYMRP-4pv-3@gated-at.bofh.it>
In reply to#1446006
On Tue, Jul 19, 2016 at 6:48 AM, Wolfram Sang <wsa@the-dreams.de> wrote:
>
>> > Well, not knowing much about ACPI, I just need the conflict resolution
>> > for my latest i2c/for-next and your above branch. If you want to do it,
>> > fine with me. But maybe Jarkko will be back to office on Monday, too.
>>
>> Unfortunately, I don't see how these branches can be merged in a sensible
>> way without adding too much new code into the merge itself.
>>
>> Something needs to be dropped and then rebased and applied again.
>
> Okay, I'll drop the I2C parts. Next to the core parts which I will drop,
> there was also a driver patch making use of the core changes for which I
> requested some updates. Since those did not happen yet (Jarkko on
> holiday?), the core patches alone are not important anyhow.

Jarkko and Mika are on holidays, I recently noticed this thread,
sorry. For now your solution seems okay, since we can't push broken
parts into v4.8-rc1.

-- 
With Best Regards,
Andy Shevchenko

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web