linux-next: manual merge of the driver-core tree with the net-next tree

linux-next: manual merge of the driver-core tree with the net-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2007 bytes --]

Hi Greg,

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

  fs/sysfs/group.c

between commit:

  5f81880d5204 ("sysfs, kobject: allow creating kobject belonging to arbitrary users")

from the net-next tree and commit:

  c855cf2759d2 ("sysfs: Fix internal_create_group() for named group updates")

from the driver-core tree.

I fixed it up (I think - 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 fs/sysfs/group.c
index c7a716c4acc9,38240410f831..000000000000
--- a/fs/sysfs/group.c
+++ b/fs/sysfs/group.c
@@@ -122,15 -118,23 +122,24 @@@ static int internal_create_group(struc
  			kobj->name, grp->name ?: "");
  		return -EINVAL;
  	}
 +	kobject_get_ownership(kobj, &uid, &gid);
  	if (grp->name) {
- 		kn = kernfs_create_dir_ns(kobj->sd, grp->name,
- 					  S_IRWXU | S_IRUGO | S_IXUGO,
- 					  uid, gid, kobj, NULL);
- 		if (IS_ERR(kn)) {
- 			if (PTR_ERR(kn) == -EEXIST)
- 				sysfs_warn_dup(kobj->sd, grp->name);
- 			return PTR_ERR(kn);
+ 		if (update) {
+ 			kn = kernfs_find_and_get(kobj->sd, grp->name);
+ 			if (!kn) {
+ 				pr_warn("Can't update unknown attr grp name: %s/%s\n",
+ 					kobj->name, grp->name);
+ 				return -EINVAL;
+ 			}
+ 		} else {
 -			kn = kernfs_create_dir(kobj->sd, grp->name,
 -					       S_IRWXU | S_IRUGO | S_IXUGO,
 -					       kobj);
++			kn = kernfs_create_dir_ns(kobj->sd, grp->name,
++						  S_IRWXU | S_IRUGO | S_IXUGO,
++						  uid, gid, kobj, NULL);
+ 			if (IS_ERR(kn)) {
+ 				if (PTR_ERR(kn) == -EEXIST)
+ 					sysfs_warn_dup(kobj->sd, grp->name);
+ 				return PTR_ERR(kn);
+ 			}
  		}
  	} else
  		kn = kobj->sd;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the driver-core tree with the net-next tree

[Greg KH]

On Mon, Jul 23, 2018 at 03:12:24PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the driver-core tree got a conflict in:
> 
>   fs/sysfs/group.c
> 
> between commit:
> 
>   5f81880d5204 ("sysfs, kobject: allow creating kobject belonging to arbitrary users")
> 
> from the net-next tree and commit:
> 
>   c855cf2759d2 ("sysfs: Fix internal_create_group() for named group updates")
> 
> from the driver-core tree.
> 
> I fixed it up (I think - 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 fs/sysfs/group.c
> index c7a716c4acc9,38240410f831..000000000000
> --- a/fs/sysfs/group.c
> +++ b/fs/sysfs/group.c
> @@@ -122,15 -118,23 +122,24 @@@ static int internal_create_group(struc
>   			kobj->name, grp->name ?: "");
>   		return -EINVAL;
>   	}
>  +	kobject_get_ownership(kobj, &uid, &gid);
>   	if (grp->name) {
> - 		kn = kernfs_create_dir_ns(kobj->sd, grp->name,
> - 					  S_IRWXU | S_IRUGO | S_IXUGO,
> - 					  uid, gid, kobj, NULL);
> - 		if (IS_ERR(kn)) {
> - 			if (PTR_ERR(kn) == -EEXIST)
> - 				sysfs_warn_dup(kobj->sd, grp->name);
> - 			return PTR_ERR(kn);
> + 		if (update) {
> + 			kn = kernfs_find_and_get(kobj->sd, grp->name);
> + 			if (!kn) {
> + 				pr_warn("Can't update unknown attr grp name: %s/%s\n",
> + 					kobj->name, grp->name);
> + 				return -EINVAL;
> + 			}
> + 		} else {
>  -			kn = kernfs_create_dir(kobj->sd, grp->name,
>  -					       S_IRWXU | S_IRUGO | S_IXUGO,
>  -					       kobj);
> ++			kn = kernfs_create_dir_ns(kobj->sd, grp->name,
> ++						  S_IRWXU | S_IRUGO | S_IXUGO,
> ++						  uid, gid, kobj, NULL);
> + 			if (IS_ERR(kn)) {
> + 				if (PTR_ERR(kn) == -EEXIST)
> + 					sysfs_warn_dup(kobj->sd, grp->name);
> + 				return PTR_ERR(kn);
> + 			}
>   		}
>   	} else
>   		kn = kobj->sd;


I think this is correct.  Rajat, can you verify it please?

thanks,

greg k-h

Re: linux-next: manual merge of the driver-core tree with the net-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2584 bytes --]

Hi all,

On Mon, 23 Jul 2018 08:20:46 +0200 Greg KH <greg@kroah.com> wrote:
>
> On Mon, Jul 23, 2018 at 03:12:24PM +1000, Stephen Rothwell wrote:
> > 
> > Today's linux-next merge of the driver-core tree got a conflict in:
> > 
> >   fs/sysfs/group.c
> > 
> > between commit:
> > 
> >   5f81880d5204 ("sysfs, kobject: allow creating kobject belonging to arbitrary users")
> > 
> > from the net-next tree and commit:
> > 
> >   c855cf2759d2 ("sysfs: Fix internal_create_group() for named group updates")
> > 
> > from the driver-core tree.
> > 
> > I fixed it up (I think - 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 fs/sysfs/group.c
> > index c7a716c4acc9,38240410f831..000000000000
> > --- a/fs/sysfs/group.c
> > +++ b/fs/sysfs/group.c
> > @@@ -122,15 -118,23 +122,24 @@@ static int internal_create_group(struc
> >   			kobj->name, grp->name ?: "");
> >   		return -EINVAL;
> >   	}
> >  +	kobject_get_ownership(kobj, &uid, &gid);
> >   	if (grp->name) {
> > - 		kn = kernfs_create_dir_ns(kobj->sd, grp->name,
> > - 					  S_IRWXU | S_IRUGO | S_IXUGO,
> > - 					  uid, gid, kobj, NULL);
> > - 		if (IS_ERR(kn)) {
> > - 			if (PTR_ERR(kn) == -EEXIST)
> > - 				sysfs_warn_dup(kobj->sd, grp->name);
> > - 			return PTR_ERR(kn);
> > + 		if (update) {
> > + 			kn = kernfs_find_and_get(kobj->sd, grp->name);
> > + 			if (!kn) {
> > + 				pr_warn("Can't update unknown attr grp name: %s/%s\n",
> > + 					kobj->name, grp->name);
> > + 				return -EINVAL;
> > + 			}
> > + 		} else {
> >  -			kn = kernfs_create_dir(kobj->sd, grp->name,
> >  -					       S_IRWXU | S_IRUGO | S_IXUGO,
> >  -					       kobj);
> > ++			kn = kernfs_create_dir_ns(kobj->sd, grp->name,
> > ++						  S_IRWXU | S_IRUGO | S_IXUGO,
> > ++						  uid, gid, kobj, NULL);
> > + 			if (IS_ERR(kn)) {
> > + 				if (PTR_ERR(kn) == -EEXIST)
> > + 					sysfs_warn_dup(kobj->sd, grp->name);
> > + 				return PTR_ERR(kn);
> > + 			}
> >   		}
> >   	} else
> >   		kn = kobj->sd;  
> 
> 
> I think this is correct.  Rajat, can you verify it please?

This is now a conflict between Linus' tree and the driver-core tree.
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the driver-core tree with the net-next tree

[Rajat Jain]

On Wed, Aug 15, 2018 at 4:43 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> On Mon, 23 Jul 2018 08:20:46 +0200 Greg KH <greg@kroah.com> wrote:
> >
> > On Mon, Jul 23, 2018 at 03:12:24PM +1000, Stephen Rothwell wrote:
> > >
> > > Today's linux-next merge of the driver-core tree got a conflict in:
> > >
> > >   fs/sysfs/group.c
> > >
> > > between commit:
> > >
> > >   5f81880d5204 ("sysfs, kobject: allow creating kobject belonging to arbitrary users")
> > >
> > > from the net-next tree and commit:
> > >
> > >   c855cf2759d2 ("sysfs: Fix internal_create_group() for named group updates")
> > >
> > > from the driver-core tree.
> > >
> > > I fixed it up (I think - 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 fs/sysfs/group.c
> > > index c7a716c4acc9,38240410f831..000000000000
> > > --- a/fs/sysfs/group.c
> > > +++ b/fs/sysfs/group.c
> > > @@@ -122,15 -118,23 +122,24 @@@ static int internal_create_group(struc
> > >                     kobj->name, grp->name ?: "");
> > >             return -EINVAL;
> > >     }
> > >  +  kobject_get_ownership(kobj, &uid, &gid);
> > >     if (grp->name) {
> > > -           kn = kernfs_create_dir_ns(kobj->sd, grp->name,
> > > -                                     S_IRWXU | S_IRUGO | S_IXUGO,
> > > -                                     uid, gid, kobj, NULL);
> > > -           if (IS_ERR(kn)) {
> > > -                   if (PTR_ERR(kn) == -EEXIST)
> > > -                           sysfs_warn_dup(kobj->sd, grp->name);
> > > -                   return PTR_ERR(kn);
> > > +           if (update) {
> > > +                   kn = kernfs_find_and_get(kobj->sd, grp->name);
> > > +                   if (!kn) {
> > > +                           pr_warn("Can't update unknown attr grp name: %s/%s\n",
> > > +                                   kobj->name, grp->name);
> > > +                           return -EINVAL;
> > > +                   }
> > > +           } else {
> > >  -                  kn = kernfs_create_dir(kobj->sd, grp->name,
> > >  -                                         S_IRWXU | S_IRUGO | S_IXUGO,
> > >  -                                         kobj);
> > > ++                  kn = kernfs_create_dir_ns(kobj->sd, grp->name,
> > > ++                                            S_IRWXU | S_IRUGO | S_IXUGO,
> > > ++                                            uid, gid, kobj, NULL);
> > > +                   if (IS_ERR(kn)) {
> > > +                           if (PTR_ERR(kn) == -EEXIST)
> > > +                                   sysfs_warn_dup(kobj->sd, grp->name);
> > > +                           return PTR_ERR(kn);
> > > +                   }
> > >             }
> > >     } else
> > >             kn = kobj->sd;
> >
> >
> > I think this is correct.  Rajat, can you verify it please?

Sorry, I saw this very late. Yes, this is correct.

>
>
> This is now a conflict between Linus' tree and the driver-core tree.

Greg, please let me know if there is anything I need to do about this.

Thanks & Best Regards,

Rajat

> --
> Cheers,
> Stephen Rothwell

Re: linux-next: manual merge of the driver-core tree with the net-next tree

[Greg KH]

On Mon, Jan 30, 2023 at 02:31:16PM +0200, Andy Shevchenko wrote:
> On Mon, Jan 30, 2023 at 03:32:29PM +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the driver-core tree got a conflict in:
> > 
> >   include/linux/acpi.h
> > 
> > between commit:
> > 
> >   1b94ad7ccc21 ("ACPI: utils: Add acpi_evaluate_dsm_typed() and acpi_check_dsm() stubs")
> > 
> > from the net-next tree and commit:
> > 
> >   162736b0d71a ("driver core: make struct device_type.uevent() take a const *")
> > 
> > from the driver-core tree.
> > 
> > I fixed it up (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.
> 
> Seems correct, thank you!

Looks good to me too, thanks!

greg k-h

Re: linux-next: manual merge of the driver-core tree with the net-next tree

[Andy Shevchenko]

On Mon, Jan 30, 2023 at 03:32:29PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the driver-core tree got a conflict in:
> 
>   include/linux/acpi.h
> 
> between commit:
> 
>   1b94ad7ccc21 ("ACPI: utils: Add acpi_evaluate_dsm_typed() and acpi_check_dsm() stubs")
> 
> from the net-next tree and commit:
> 
>   162736b0d71a ("driver core: make struct device_type.uevent() take a const *")
> 
> from the driver-core tree.
> 
> I fixed it up (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.

Seems correct, thank you!

-- 
With Best Regards,
Andy Shevchenko

linux-next: manual merge of the driver-core tree with the net-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]

Hi all,

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

  include/linux/acpi.h

between commit:

  1b94ad7ccc21 ("ACPI: utils: Add acpi_evaluate_dsm_typed() and acpi_check_dsm() stubs")

from the net-next tree and commit:

  162736b0d71a ("driver core: make struct device_type.uevent() take a const *")

from the driver-core tree.

I fixed it up (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 include/linux/acpi.h
index 4b12dad5a8a4,564b62f13bd0..000000000000
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@@ -964,16 -958,7 +964,16 @@@ static inline union acpi_object *acpi_e
  	return NULL;
  }
  
 +static inline union acpi_object *acpi_evaluate_dsm_typed(acpi_handle handle,
 +							 const guid_t *guid,
 +							 u64 rev, u64 func,
 +							 union acpi_object *argv4,
 +							 acpi_object_type type)
 +{
 +	return NULL;
 +}
 +
- static inline int acpi_device_uevent_modalias(struct device *dev,
+ static inline int acpi_device_uevent_modalias(const struct device *dev,
  				struct kobj_uevent_env *env)
  {
  	return -ENODEV;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the driver-core tree with the net-next tree

[Arend van Spriel]

On 04-12-14 11:19, Jeremiah Mahler wrote:
> Arend,
> 
> I haven't heard if you have looked at this bug at all yet.  I was
> curious so I looked at it some more and I have some more information
> that might be helpful.
> 
> On Wed, Dec 03, 2014 at 01:41:28PM -0800, Jeremiah Mahler wrote:
>> On Wed, Dec 03, 2014 at 01:06:59PM -0800, Jeremiah Mahler wrote:
>>> Arend,
>>>
> [...]
>>>>>
>>>>> I took a look at the patch that is causing this problem (d32394fae95).
>>>>> My config negates everything in the patch except for a one line change
>>>>> to ath9k/pci.c.  If I remove this change (shown below) the problem goes
>>>>> away.
>>>>
>>>> Ok. But then it will likely crash when you cat one of the changed debugfs
>>>> files. Guess this commit needs to be reverted entirely.
>>>>
> [...]
> 
> Referring to the code snippet below, notice that both pci_set_drvdata()
> and dev_set_drvdata() are called.  If the call to dev_set_drvdata() is
> removed the bug goes away.
> 
>   drivers/net/wireless/ath/ath9k/pci.c
> 
>   861     SET_IEEE80211_DEV(hw, &pdev->dev);
>   862     pci_set_drvdata(pdev, hw);
>   863
>   864     sc = hw->priv;
>   865     sc->hw = hw;
>   866     sc->dev = &pdev->dev;
>   867     dev_set_drvdata(sc->dev, sc);
>   868     sc->mem = pcim_iomap_table(pdev)[0];
>   869     sc->driver_data = id->driver_data;
> 
> Translating the call to pci_set_drvdata() produces the following.
> 
>   pci_set_drvdata(pdev, hw);
>     (translating from include/linux/pci.h)
>     dev_set_drvdata(&pdev->dev, hw)
>       (translating from include/linux/device.h)
>       &pdev->dev->driver = hw;
> 
> And doing the same for dev_set_drvdata().
> 
>   dev_set_drvdata(sc->dev, sc)
>     (sc->dev = &pdev->dev)
>     dev_set_drvdata(&pdev->dev, sc)
>       (translating from include/linux/device.h)
>       &pdev->dev->driver = sc;
> 
> The same destination is being set with two different values.  Then calls
> to pci_get_drvdata(), which expect hw, are getting sc, and it breaks.

Yes, that was my suspicion as well. This is why I asked to revert the
patch entirely. I see that sc equals hw->priv so I know how to correct
it. However, with merge window around the corner it may be easier to do
a revert.

Regards,
Arend

Re: linux-next: manual merge of the driver-core tree with the net-next tree

[Jeremiah Mahler]

Arend,

I haven't heard if you have looked at this bug at all yet.  I was
curious so I looked at it some more and I have some more information
that might be helpful.

On Wed, Dec 03, 2014 at 01:41:28PM -0800, Jeremiah Mahler wrote:
> On Wed, Dec 03, 2014 at 01:06:59PM -0800, Jeremiah Mahler wrote:
> > Arend,
> > 
[...]
> > > >
> > > >I took a look at the patch that is causing this problem (d32394fae95).
> > > >My config negates everything in the patch except for a one line change
> > > >to ath9k/pci.c.  If I remove this change (shown below) the problem goes
> > > >away.
> > > 
> > > Ok. But then it will likely crash when you cat one of the changed debugfs
> > > files. Guess this commit needs to be reverted entirely.
> > > 
[...]

Referring to the code snippet below, notice that both pci_set_drvdata()
and dev_set_drvdata() are called.  If the call to dev_set_drvdata() is
removed the bug goes away.

  drivers/net/wireless/ath/ath9k/pci.c

  861     SET_IEEE80211_DEV(hw, &pdev->dev);
  862     pci_set_drvdata(pdev, hw);
  863
  864     sc = hw->priv;
  865     sc->hw = hw;
  866     sc->dev = &pdev->dev;
  867     dev_set_drvdata(sc->dev, sc);
  868     sc->mem = pcim_iomap_table(pdev)[0];
  869     sc->driver_data = id->driver_data;

Translating the call to pci_set_drvdata() produces the following.

  pci_set_drvdata(pdev, hw);
    (translating from include/linux/pci.h)
    dev_set_drvdata(&pdev->dev, hw)
      (translating from include/linux/device.h)
      &pdev->dev->driver = hw;

And doing the same for dev_set_drvdata().

  dev_set_drvdata(sc->dev, sc)
    (sc->dev = &pdev->dev)
    dev_set_drvdata(&pdev->dev, sc)
      (translating from include/linux/device.h)
      &pdev->dev->driver = sc;

The same destination is being set with two different values.  Then calls
to pci_get_drvdata(), which expect hw, are getting sc, and it breaks.

-- 
- Jeremiah Mahler

Re: linux-next: manual merge of the driver-core tree with the net-next tree

[Jeremiah Mahler]

On Wed, Dec 03, 2014 at 01:06:59PM -0800, Jeremiah Mahler wrote:
> Arend,
> 
> On Wed, Dec 03, 2014 at 01:49:00PM +0100, Arend van Spriel wrote:
> > On 12/03/14 11:51, Jeremiah Mahler wrote:
> > >On Wed, Dec 03, 2014 at 12:36:55AM -0800, Jeremiah Mahler wrote:
> > >>all,
> > >>
> > >>On Mon, Dec 01, 2014 at 08:34:05AM +0100, Arend van Spriel wrote:
> > >>>On 01-12-14 08:19, Stephen Rothwell wrote:
> > >>>>Hi Greg,
> > >>>>
[...]
> > >
> > >I took a look at the patch that is causing this problem (d32394fae95).
> > >My config negates everything in the patch except for a one line change
> > >to ath9k/pci.c.  If I remove this change (shown below) the problem goes
> > >away.
> > 
> > Ok. But then it will likely crash when you cat one of the changed debugfs
> > files. Guess this commit needs to be reverted entirely.
> > 
> 
> On my machine ATH9K_DEBUFS is disabled so none of that code is used.
> 
> I can try enabling it and see if a cat will crash it.
> 

With ATH9K_DEBUGFS enabled, cat works fine on the files that were
changed.

/sys/kernel/debug/ieee80211/phy0/ath9k/
  dma
  interrupt
  xmit
  queues

> > Regards,
> > Arend
> > 
[...]
> 
> -- 
> - Jeremiah Mahler

-- 
- Jeremiah Mahler

Re: linux-next: manual merge of the driver-core tree with the net-next tree

[Jeremiah Mahler]

Arend,

On Wed, Dec 03, 2014 at 01:49:00PM +0100, Arend van Spriel wrote:
> On 12/03/14 11:51, Jeremiah Mahler wrote:
> >On Wed, Dec 03, 2014 at 12:36:55AM -0800, Jeremiah Mahler wrote:
> >>all,
> >>
> >>On Mon, Dec 01, 2014 at 08:34:05AM +0100, Arend van Spriel wrote:
> >>>On 01-12-14 08:19, Stephen Rothwell wrote:
> >>>>Hi Greg,
> >>>>
> >>>>Today's linux-next merge of the driver-core tree got a conflict in
> >>>>drivers/net/wireless/ath/ath9k/debug.c between commits 70e535ed0029
> >>>>("ath9k: clean up debugfs print of reset causes"), 7b8aaead958e
> >>>>("ath9k: restart hardware after noise floor calibration failure") and
> >>>>325e18817668 ("ath9k: fix misc debugfs when not using chan context")
> >>>>from the net-next tree and commit 631bee257bd5 ("ath: use seq_file api
> >>>>for ath9k debugfs files") from the driver-core tree.
> >>>>
> >>>>I fixed it up (see below) and can carry the fix as necessary (no action
> >>>>is required).
> >>>>
> >>>>Greg, I am not sure why those 2 commits are even in your tree.  Do they
> >>>>depend on something else in your tree?
> >>>
> >>>They do. The three commits below are related:
> >>>
> >>>d32394f ath: ath9k: use debugfs_create_devm_seqfile() helper for
> >>>seq_file entrie
> >>>631bee2 ath: use seq_file api for ath9k debugfs files
> >>>98210b7 debugfs: add helper function to create device related seq_file
> >>>
> >>>The ath patches were made to provide example of using the new helper
> >>>function and get some idea about code savings. Greg and John discussed
> >>>who would take them. I noticed other ath changes in net-next so I kinda
> >>>expected this email ;-)
> >>>
> >>>Regards,
> >>>Arend
> >>>--
> >>>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >>>the body of a message to majordomo@vger.kernel.org
> >>>More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>>Please read the FAQ at  http://www.tux.org/lkml/
> >>
> >>I just ran in to a problem with one of these commits.
> >>
> >>On an Acer C720 laptop if a suspend is performed the screen freezes,
> >>the machine locks up, and according to the indicator lights it does
> >>not enter suspend.  A hard reset is required to get it running again.
> >>
> >>I have bisected the kernel and found that the following is the first bad
> >>commit.
> >>
> >>   commit d32394fae95741d733b174ec1446f27765f80233
> >>   Author: Arend van Spriel<arend@broadcom.com>
> >>   Date:   Sun Nov 9 11:32:00 2014 +0100
> >>
> >>       ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file
> >>   entries
> >>
> >>       Use the helper to get rid of the file operations per debugfs file.
> >>   The
> >>       struct ath9k_softc pointer is set as device driver data to be
> >>   obtained
> >>       in the seq_file read operation.
> >>
> >>       Signed-off-by: Arend van Spriel<arend@broadcom.com>
> >>       Signed-off-by: Greg Kroah-Hartman<gregkh@linuxfoundation.org>
> >>
> >>Let me know if I can do anything else to help.
> >>
> >>--
> >>- Jeremiah Mahler
> >
> >I took a look at the patch that is causing this problem (d32394fae95).
> >My config negates everything in the patch except for a one line change
> >to ath9k/pci.c.  If I remove this change (shown below) the problem goes
> >away.
> 
> Ok. But then it will likely crash when you cat one of the changed debugfs
> files. Guess this commit needs to be reverted entirely.
> 

On my machine ATH9K_DEBUFS is disabled so none of that code is used.

I can try enabling it and see if a cat will crash it.

> Regards,
> Arend
> 
> >diff --git a/drivers/net/wireless/ath/ath9k/pci.c
> >b/drivers/net/wireless/ath/ath9k/pci.c
> >index 90c9e3c..c018dea 100644
> >--- a/drivers/net/wireless/ath/ath9k/pci.c
> >+++ b/drivers/net/wireless/ath/ath9k/pci.c
> >@@ -856,7 +856,6 @@ static int ath_pci_probe(struct pci_dev *pdev, const
> >struct pci_device_id *id)
> >         sc = hw->priv;
> >         sc->hw = hw;
> >         sc->dev =&pdev->dev;
> >-       dev_set_drvdata(sc->dev, sc);
> >         sc->mem = pcim_iomap_table(pdev)[0];
> >         sc->driver_data = id->driver_data;
> >
> 

-- 
- Jeremiah Mahler

Re: linux-next: manual merge of the driver-core tree with the net-next tree

[Arend van Spriel]

On 12/03/14 17:21, Greg KH wrote:
> On Wed, Dec 03, 2014 at 01:49:00PM +0100, Arend van Spriel wrote:
>> On 12/03/14 11:51, Jeremiah Mahler wrote:
>>> On Wed, Dec 03, 2014 at 12:36:55AM -0800, Jeremiah Mahler wrote:
>>>> all,
>>>>
>>>> On Mon, Dec 01, 2014 at 08:34:05AM +0100, Arend van Spriel wrote:
>>>>> On 01-12-14 08:19, Stephen Rothwell wrote:
>>>>>> Hi Greg,
>>>>>>
>>>>>> Today's linux-next merge of the driver-core tree got a conflict in
>>>>>> drivers/net/wireless/ath/ath9k/debug.c between commits 70e535ed0029
>>>>>> ("ath9k: clean up debugfs print of reset causes"), 7b8aaead958e
>>>>>> ("ath9k: restart hardware after noise floor calibration failure") and
>>>>>> 325e18817668 ("ath9k: fix misc debugfs when not using chan context")
>>>>> >from the net-next tree and commit 631bee257bd5 ("ath: use seq_file api
>>>>>> for ath9k debugfs files") from the driver-core tree.
>>>>>>
>>>>>> I fixed it up (see below) and can carry the fix as necessary (no action
>>>>>> is required).
>>>>>>
>>>>>> Greg, I am not sure why those 2 commits are even in your tree.  Do they
>>>>>> depend on something else in your tree?
>>>>>
>>>>> They do. The three commits below are related:
>>>>>
>>>>> d32394f ath: ath9k: use debugfs_create_devm_seqfile() helper for
>>>>> seq_file entrie
>>>>> 631bee2 ath: use seq_file api for ath9k debugfs files
>>>>> 98210b7 debugfs: add helper function to create device related seq_file
>>>>>
>>>>> The ath patches were made to provide example of using the new helper
>>>>> function and get some idea about code savings. Greg and John discussed
>>>>> who would take them. I noticed other ath changes in net-next so I kinda
>>>>> expected this email ;-)
>>>>>
>>>>> Regards,
>>>>> Arend
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>> Please read the FAQ at  http://www.tux.org/lkml/
>>>>
>>>> I just ran in to a problem with one of these commits.
>>>>
>>>> On an Acer C720 laptop if a suspend is performed the screen freezes,
>>>> the machine locks up, and according to the indicator lights it does
>>>> not enter suspend.  A hard reset is required to get it running again.
>>>>
>>>> I have bisected the kernel and found that the following is the first bad
>>>> commit.
>>>>
>>>>    commit d32394fae95741d733b174ec1446f27765f80233
>>>>    Author: Arend van Spriel<arend@broadcom.com>
>>>>    Date:   Sun Nov 9 11:32:00 2014 +0100
>>>>
>>>>        ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file
>>>>    entries
>>>>
>>>>        Use the helper to get rid of the file operations per debugfs file.
>>>>    The
>>>>        struct ath9k_softc pointer is set as device driver data to be
>>>>    obtained
>>>>        in the seq_file read operation.
>>>>
>>>>        Signed-off-by: Arend van Spriel<arend@broadcom.com>
>>>>        Signed-off-by: Greg Kroah-Hartman<gregkh@linuxfoundation.org>
>>>>
>>>> Let me know if I can do anything else to help.
>>>>
>>>> --
>>>> - Jeremiah Mahler
>>>
>>> I took a look at the patch that is causing this problem (d32394fae95).
>>> My config negates everything in the patch except for a one line change
>>> to ath9k/pci.c.  If I remove this change (shown below) the problem goes
>>> away.
>>
>> Ok. But then it will likely crash when you cat one of the changed debugfs
>> files. Guess this commit needs to be reverted entirely.
>
> What commit, d32394fae95741d733b174ec1446f27765f80233?

Indeed.

Regards,
Arend

Re: linux-next: manual merge of the driver-core tree with the net-next tree

[Greg KH]

On Wed, Dec 03, 2014 at 01:49:00PM +0100, Arend van Spriel wrote:
> On 12/03/14 11:51, Jeremiah Mahler wrote:
> >On Wed, Dec 03, 2014 at 12:36:55AM -0800, Jeremiah Mahler wrote:
> >>all,
> >>
> >>On Mon, Dec 01, 2014 at 08:34:05AM +0100, Arend van Spriel wrote:
> >>>On 01-12-14 08:19, Stephen Rothwell wrote:
> >>>>Hi Greg,
> >>>>
> >>>>Today's linux-next merge of the driver-core tree got a conflict in
> >>>>drivers/net/wireless/ath/ath9k/debug.c between commits 70e535ed0029
> >>>>("ath9k: clean up debugfs print of reset causes"), 7b8aaead958e
> >>>>("ath9k: restart hardware after noise floor calibration failure") and
> >>>>325e18817668 ("ath9k: fix misc debugfs when not using chan context")
> >>>>from the net-next tree and commit 631bee257bd5 ("ath: use seq_file api
> >>>>for ath9k debugfs files") from the driver-core tree.
> >>>>
> >>>>I fixed it up (see below) and can carry the fix as necessary (no action
> >>>>is required).
> >>>>
> >>>>Greg, I am not sure why those 2 commits are even in your tree.  Do they
> >>>>depend on something else in your tree?
> >>>
> >>>They do. The three commits below are related:
> >>>
> >>>d32394f ath: ath9k: use debugfs_create_devm_seqfile() helper for
> >>>seq_file entrie
> >>>631bee2 ath: use seq_file api for ath9k debugfs files
> >>>98210b7 debugfs: add helper function to create device related seq_file
> >>>
> >>>The ath patches were made to provide example of using the new helper
> >>>function and get some idea about code savings. Greg and John discussed
> >>>who would take them. I noticed other ath changes in net-next so I kinda
> >>>expected this email ;-)
> >>>
> >>>Regards,
> >>>Arend
> >>>--
> >>>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >>>the body of a message to majordomo@vger.kernel.org
> >>>More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>>Please read the FAQ at  http://www.tux.org/lkml/
> >>
> >>I just ran in to a problem with one of these commits.
> >>
> >>On an Acer C720 laptop if a suspend is performed the screen freezes,
> >>the machine locks up, and according to the indicator lights it does
> >>not enter suspend.  A hard reset is required to get it running again.
> >>
> >>I have bisected the kernel and found that the following is the first bad
> >>commit.
> >>
> >>   commit d32394fae95741d733b174ec1446f27765f80233
> >>   Author: Arend van Spriel<arend@broadcom.com>
> >>   Date:   Sun Nov 9 11:32:00 2014 +0100
> >>
> >>       ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file
> >>   entries
> >>
> >>       Use the helper to get rid of the file operations per debugfs file.
> >>   The
> >>       struct ath9k_softc pointer is set as device driver data to be
> >>   obtained
> >>       in the seq_file read operation.
> >>
> >>       Signed-off-by: Arend van Spriel<arend@broadcom.com>
> >>       Signed-off-by: Greg Kroah-Hartman<gregkh@linuxfoundation.org>
> >>
> >>Let me know if I can do anything else to help.
> >>
> >>--
> >>- Jeremiah Mahler
> >
> >I took a look at the patch that is causing this problem (d32394fae95).
> >My config negates everything in the patch except for a one line change
> >to ath9k/pci.c.  If I remove this change (shown below) the problem goes
> >away.
> 
> Ok. But then it will likely crash when you cat one of the changed debugfs
> files. Guess this commit needs to be reverted entirely.

What commit, d32394fae95741d733b174ec1446f27765f80233?

Re: linux-next: manual merge of the driver-core tree with the net-next tree

[Arend van Spriel]

On 12/03/14 11:51, Jeremiah Mahler wrote:
> On Wed, Dec 03, 2014 at 12:36:55AM -0800, Jeremiah Mahler wrote:
>> all,
>>
>> On Mon, Dec 01, 2014 at 08:34:05AM +0100, Arend van Spriel wrote:
>>> On 01-12-14 08:19, Stephen Rothwell wrote:
>>>> Hi Greg,
>>>>
>>>> Today's linux-next merge of the driver-core tree got a conflict in
>>>> drivers/net/wireless/ath/ath9k/debug.c between commits 70e535ed0029
>>>> ("ath9k: clean up debugfs print of reset causes"), 7b8aaead958e
>>>> ("ath9k: restart hardware after noise floor calibration failure") and
>>>> 325e18817668 ("ath9k: fix misc debugfs when not using chan context")
>>>> from the net-next tree and commit 631bee257bd5 ("ath: use seq_file api
>>>> for ath9k debugfs files") from the driver-core tree.
>>>>
>>>> I fixed it up (see below) and can carry the fix as necessary (no action
>>>> is required).
>>>>
>>>> Greg, I am not sure why those 2 commits are even in your tree.  Do they
>>>> depend on something else in your tree?
>>>
>>> They do. The three commits below are related:
>>>
>>> d32394f ath: ath9k: use debugfs_create_devm_seqfile() helper for
>>> seq_file entrie
>>> 631bee2 ath: use seq_file api for ath9k debugfs files
>>> 98210b7 debugfs: add helper function to create device related seq_file
>>>
>>> The ath patches were made to provide example of using the new helper
>>> function and get some idea about code savings. Greg and John discussed
>>> who would take them. I noticed other ath changes in net-next so I kinda
>>> expected this email ;-)
>>>
>>> Regards,
>>> Arend
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>> Please read the FAQ at  http://www.tux.org/lkml/
>>
>> I just ran in to a problem with one of these commits.
>>
>> On an Acer C720 laptop if a suspend is performed the screen freezes,
>> the machine locks up, and according to the indicator lights it does
>> not enter suspend.  A hard reset is required to get it running again.
>>
>> I have bisected the kernel and found that the following is the first bad
>> commit.
>>
>>    commit d32394fae95741d733b174ec1446f27765f80233
>>    Author: Arend van Spriel<arend@broadcom.com>
>>    Date:   Sun Nov 9 11:32:00 2014 +0100
>>
>>        ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file
>>    entries
>>
>>        Use the helper to get rid of the file operations per debugfs file.
>>    The
>>        struct ath9k_softc pointer is set as device driver data to be
>>    obtained
>>        in the seq_file read operation.
>>
>>        Signed-off-by: Arend van Spriel<arend@broadcom.com>
>>        Signed-off-by: Greg Kroah-Hartman<gregkh@linuxfoundation.org>
>>
>> Let me know if I can do anything else to help.
>>
>> --
>> - Jeremiah Mahler
>
> I took a look at the patch that is causing this problem (d32394fae95).
> My config negates everything in the patch except for a one line change
> to ath9k/pci.c.  If I remove this change (shown below) the problem goes
> away.

Ok. But then it will likely crash when you cat one of the changed 
debugfs files. Guess this commit needs to be reverted entirely.

Regards,
Arend

> diff --git a/drivers/net/wireless/ath/ath9k/pci.c
> b/drivers/net/wireless/ath/ath9k/pci.c
> index 90c9e3c..c018dea 100644
> --- a/drivers/net/wireless/ath/ath9k/pci.c
> +++ b/drivers/net/wireless/ath/ath9k/pci.c
> @@ -856,7 +856,6 @@ static int ath_pci_probe(struct pci_dev *pdev, const
> struct pci_device_id *id)
>          sc = hw->priv;
>          sc->hw = hw;
>          sc->dev =&pdev->dev;
> -       dev_set_drvdata(sc->dev, sc);
>          sc->mem = pcim_iomap_table(pdev)[0];
>          sc->driver_data = id->driver_data;
>

Re: linux-next: manual merge of the driver-core tree with the net-next tree

[Jeremiah Mahler]

On Wed, Dec 03, 2014 at 12:36:55AM -0800, Jeremiah Mahler wrote:
> all,
> 
> On Mon, Dec 01, 2014 at 08:34:05AM +0100, Arend van Spriel wrote:
> > On 01-12-14 08:19, Stephen Rothwell wrote:
> > > Hi Greg,
> > > 
> > > Today's linux-next merge of the driver-core tree got a conflict in
> > > drivers/net/wireless/ath/ath9k/debug.c between commits 70e535ed0029
> > > ("ath9k: clean up debugfs print of reset causes"), 7b8aaead958e
> > > ("ath9k: restart hardware after noise floor calibration failure") and
> > > 325e18817668 ("ath9k: fix misc debugfs when not using chan context")
> > > from the net-next tree and commit 631bee257bd5 ("ath: use seq_file api
> > > for ath9k debugfs files") from the driver-core tree.
> > > 
> > > I fixed it up (see below) and can carry the fix as necessary (no action
> > > is required).
> > > 
> > > Greg, I am not sure why those 2 commits are even in your tree.  Do they
> > > depend on something else in your tree?
> > 
> > They do. The three commits below are related:
> > 
> > d32394f ath: ath9k: use debugfs_create_devm_seqfile() helper for
> > seq_file entrie
> > 631bee2 ath: use seq_file api for ath9k debugfs files
> > 98210b7 debugfs: add helper function to create device related seq_file
> > 
> > The ath patches were made to provide example of using the new helper
> > function and get some idea about code savings. Greg and John discussed
> > who would take them. I noticed other ath changes in net-next so I kinda
> > expected this email ;-)
> > 
> > Regards,
> > Arend
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> 
> I just ran in to a problem with one of these commits.
> 
> On an Acer C720 laptop if a suspend is performed the screen freezes,
> the machine locks up, and according to the indicator lights it does
> not enter suspend.  A hard reset is required to get it running again.
> 
> I have bisected the kernel and found that the following is the first bad
> commit.
> 
>   commit d32394fae95741d733b174ec1446f27765f80233
>   Author: Arend van Spriel <arend@broadcom.com>
>   Date:   Sun Nov 9 11:32:00 2014 +0100
>   
>       ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file
>   entries
>       
>       Use the helper to get rid of the file operations per debugfs file.
>   The
>       struct ath9k_softc pointer is set as device driver data to be
>   obtained
>       in the seq_file read operation.
>       
>       Signed-off-by: Arend van Spriel <arend@broadcom.com>
>       Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 
> Let me know if I can do anything else to help.
> 
> -- 
> - Jeremiah Mahler

I took a look at the patch that is causing this problem (d32394fae95).
My config negates everything in the patch except for a one line change
to ath9k/pci.c.  If I remove this change (shown below) the problem goes
away.

diff --git a/drivers/net/wireless/ath/ath9k/pci.c
b/drivers/net/wireless/ath/ath9k/pci.c
index 90c9e3c..c018dea 100644
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -856,7 +856,6 @@ static int ath_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *id)
        sc = hw->priv;
        sc->hw = hw;
        sc->dev = &pdev->dev;
-       dev_set_drvdata(sc->dev, sc);
        sc->mem = pcim_iomap_table(pdev)[0];
        sc->driver_data = id->driver_data;

-- 
- Jeremiah Mahler

Re: linux-next: manual merge of the driver-core tree with the net-next tree

[Jeremiah Mahler]

all,

On Mon, Dec 01, 2014 at 08:34:05AM +0100, Arend van Spriel wrote:
> On 01-12-14 08:19, Stephen Rothwell wrote:
> > Hi Greg,
> > 
> > Today's linux-next merge of the driver-core tree got a conflict in
> > drivers/net/wireless/ath/ath9k/debug.c between commits 70e535ed0029
> > ("ath9k: clean up debugfs print of reset causes"), 7b8aaead958e
> > ("ath9k: restart hardware after noise floor calibration failure") and
> > 325e18817668 ("ath9k: fix misc debugfs when not using chan context")
> > from the net-next tree and commit 631bee257bd5 ("ath: use seq_file api
> > for ath9k debugfs files") from the driver-core tree.
> > 
> > I fixed it up (see below) and can carry the fix as necessary (no action
> > is required).
> > 
> > Greg, I am not sure why those 2 commits are even in your tree.  Do they
> > depend on something else in your tree?
> 
> They do. The three commits below are related:
> 
> d32394f ath: ath9k: use debugfs_create_devm_seqfile() helper for
> seq_file entrie
> 631bee2 ath: use seq_file api for ath9k debugfs files
> 98210b7 debugfs: add helper function to create device related seq_file
> 
> The ath patches were made to provide example of using the new helper
> function and get some idea about code savings. Greg and John discussed
> who would take them. I noticed other ath changes in net-next so I kinda
> expected this email ;-)
> 
> Regards,
> Arend
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

I just ran in to a problem with one of these commits.

On an Acer C720 laptop if a suspend is performed the screen freezes,
the machine locks up, and according to the indicator lights it does
not enter suspend.  A hard reset is required to get it running again.

I have bisected the kernel and found that the following is the first bad
commit.

  commit d32394fae95741d733b174ec1446f27765f80233
  Author: Arend van Spriel <arend@broadcom.com>
  Date:   Sun Nov 9 11:32:00 2014 +0100
  
      ath: ath9k: use debugfs_create_devm_seqfile() helper for seq_file
  entries
      
      Use the helper to get rid of the file operations per debugfs file.
  The
      struct ath9k_softc pointer is set as device driver data to be
  obtained
      in the seq_file read operation.
      
      Signed-off-by: Arend van Spriel <arend@broadcom.com>
      Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Let me know if I can do anything else to help.

-- 
- Jeremiah Mahler

Re: linux-next: manual merge of the driver-core tree with the net-next tree

[Arend van Spriel]

On 01-12-14 08:19, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the driver-core tree got a conflict in
> drivers/net/wireless/ath/ath9k/debug.c between commits 70e535ed0029
> ("ath9k: clean up debugfs print of reset causes"), 7b8aaead958e
> ("ath9k: restart hardware after noise floor calibration failure") and
> 325e18817668 ("ath9k: fix misc debugfs when not using chan context")
> from the net-next tree and commit 631bee257bd5 ("ath: use seq_file api
> for ath9k debugfs files") from the driver-core tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).
> 
> Greg, I am not sure why those 2 commits are even in your tree.  Do they
> depend on something else in your tree?

They do. The three commits below are related:

d32394f ath: ath9k: use debugfs_create_devm_seqfile() helper for
seq_file entrie
631bee2 ath: use seq_file api for ath9k debugfs files
98210b7 debugfs: add helper function to create device related seq_file

The ath patches were made to provide example of using the new helper
function and get some idea about code savings. Greg and John discussed
who would take them. I noticed other ath changes in net-next so I kinda
expected this email ;-)

Regards,
Arend

linux-next: manual merge of the driver-core tree with the net-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 5787 bytes --]

Hi Greg,

Today's linux-next merge of the driver-core tree got a conflict in
drivers/net/wireless/ath/ath9k/debug.c between commits 70e535ed0029
("ath9k: clean up debugfs print of reset causes"), 7b8aaead958e
("ath9k: restart hardware after noise floor calibration failure") and
325e18817668 ("ath9k: fix misc debugfs when not using chan context")
from the net-next tree and commit 631bee257bd5 ("ath: use seq_file api
for ath9k debugfs files") from the driver-core tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

Greg, I am not sure why those 2 commits are even in your tree.  Do they
depend on something else in your tree?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/net/wireless/ath/ath9k/debug.c
index 696e3d5309c6,a1f1614a05c2..000000000000
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@@ -832,57 -731,42 +731,46 @@@ static int read_file_misc(struct seq_fi
  			continue;
  		ath9k_calculate_iter_data(sc, ctx, &iter_data);
  
- 		len += scnprintf(buf + len, sizeof(buf) - len,
- 			"VIFS: CTX %i(%i) AP: %i STA: %i MESH: %i WDS: %i",
- 			i++, (int)(ctx->assigned), iter_data.naps,
- 			iter_data.nstations,
- 			iter_data.nmeshes, iter_data.nwds);
- 		len += scnprintf(buf + len, sizeof(buf) - len,
- 			" ADHOC: %i TOTAL: %hi BEACON-VIF: %hi\n",
- 			iter_data.nadhocs, sc->cur_chan->nvifs, sc->nbcnvifs);
+ 		seq_printf(file,
 -			   "VIF-COUNTS: CTX %i AP: %i STA: %i MESH: %i WDS: %i",
 -			   i++, iter_data.naps, iter_data.nstations,
++			   "VIFS: CTX %i(%i) AP: %i STA: %i MESH: %i WDS: %i",
++			   i++, (int)(ctx->assigned), iter_data.naps,
++			   iter_data.nstations,
+ 			   iter_data.nmeshes, iter_data.nwds);
+ 		seq_printf(file, " ADHOC: %i TOTAL: %hi BEACON-VIF: %hi\n",
+ 			   iter_data.nadhocs, sc->cur_chan->nvifs,
+ 			   sc->nbcnvifs);
  	}
  
- 	if (len > sizeof(buf))
- 		len = sizeof(buf);
- 
- 	retval = simple_read_from_buffer(user_buf, count, ppos, buf, len);
- 	return retval;
+ 	return 0;
  }
  
- static ssize_t read_file_reset(struct file *file, char __user *user_buf,
- 			       size_t count, loff_t *ppos)
+ static int read_file_reset(struct seq_file *file, void *data)
  {
- 	struct ath_softc *sc = file->private_data;
+ 	struct ath_softc *sc = dev_get_drvdata(file->private);
 +	static const char * const reset_cause[__RESET_TYPE_MAX] = {
 +		[RESET_TYPE_BB_HANG] = "Baseband Hang",
 +		[RESET_TYPE_BB_WATCHDOG] = "Baseband Watchdog",
 +		[RESET_TYPE_FATAL_INT] = "Fatal HW Error",
 +		[RESET_TYPE_TX_ERROR] = "TX HW error",
 +		[RESET_TYPE_TX_GTT] = "Transmit timeout",
 +		[RESET_TYPE_TX_HANG] = "TX Path Hang",
 +		[RESET_TYPE_PLL_HANG] = "PLL RX Hang",
 +		[RESET_TYPE_MAC_HANG] = "MAC Hang",
 +		[RESET_TYPE_BEACON_STUCK] = "Stuck Beacon",
 +		[RESET_TYPE_MCI] = "MCI Reset",
 +		[RESET_TYPE_CALIBRATION] = "Calibration error",
 +	};
- 	char buf[512];
- 	unsigned int len = 0;
 +	int i;
  
 -	seq_printf(file, "%17s: %2d\n", "Baseband Hang",
 -		   sc->debug.stats.reset[RESET_TYPE_BB_HANG]);
 -	seq_printf(file, "%17s: %2d\n", "Baseband Watchdog",
 -		   sc->debug.stats.reset[RESET_TYPE_BB_WATCHDOG]);
 -	seq_printf(file, "%17s: %2d\n", "Fatal HW Error",
 -		   sc->debug.stats.reset[RESET_TYPE_FATAL_INT]);
 -	seq_printf(file, "%17s: %2d\n", "TX HW error",
 -		   sc->debug.stats.reset[RESET_TYPE_TX_ERROR]);
 -	seq_printf(file, "%17s: %2d\n", "TX Path Hang",
 -		   sc->debug.stats.reset[RESET_TYPE_TX_HANG]);
 -	seq_printf(file, "%17s: %2d\n", "PLL RX Hang",
 -		   sc->debug.stats.reset[RESET_TYPE_PLL_HANG]);
 -	seq_printf(file, "%17s: %2d\n", "MAC Hang",
 -		   sc->debug.stats.reset[RESET_TYPE_MAC_HANG]);
 -	seq_printf(file, "%17s: %2d\n", "Stuck Beacon",
 -		   sc->debug.stats.reset[RESET_TYPE_BEACON_STUCK]);
 -	seq_printf(file, "%17s: %2d\n", "MCI Reset",
 -		   sc->debug.stats.reset[RESET_TYPE_MCI]);
 +	for (i = 0; i < ARRAY_SIZE(reset_cause); i++) {
 +		if (!reset_cause[i])
 +		    continue;
 +
- 		len += scnprintf(buf + len, sizeof(buf) - len,
- 				 "%17s: %2d\n", reset_cause[i],
- 				 sc->debug.stats.reset[i]);
++		seq_printf(file, "%17s: %2d\n", reset_cause[i],
++			   sc->debug.stats.reset[i]);
 +	}
  
- 	if (len > sizeof(buf))
- 		len = sizeof(buf);
- 
- 	return simple_read_from_buffer(user_buf, count, ppos, buf, len);
+ 	return 0;
  }
  
  void ath_debug_stat_tx(struct ath_softc *sc, struct ath_buf *bf,
@@@ -1331,16 -1175,16 +1179,16 @@@ int ath9k_init_debug(struct ath_hw *ah
  
  	ath9k_dfs_init_debug(sc);
  	ath9k_tx99_init_debug(sc);
 -	ath9k_spectral_init_debug(sc);
 +	ath9k_cmn_spectral_init_debug(&sc->spec_priv, sc->debug.debugfs_phy);
  
- 	debugfs_create_file("dma", S_IRUSR, sc->debug.debugfs_phy, sc,
- 			    &fops_dma);
- 	debugfs_create_file("interrupt", S_IRUSR, sc->debug.debugfs_phy, sc,
- 			    &fops_interrupt);
- 	debugfs_create_file("xmit", S_IRUSR, sc->debug.debugfs_phy, sc,
- 			    &fops_xmit);
- 	debugfs_create_file("queues", S_IRUSR, sc->debug.debugfs_phy, sc,
- 			    &fops_queues);
+ 	debugfs_create_devm_seqfile(sc->dev, "dma", sc->debug.debugfs_phy,
+ 				    read_file_dma);
+ 	debugfs_create_devm_seqfile(sc->dev, "interrupt", sc->debug.debugfs_phy,
+ 				    read_file_interrupt);
+ 	debugfs_create_devm_seqfile(sc->dev, "xmit", sc->debug.debugfs_phy,
+ 				    read_file_xmit);
+ 	debugfs_create_devm_seqfile(sc->dev, "queues", sc->debug.debugfs_phy,
+ 				    read_file_queues);
  	debugfs_create_u32("qlen_bk", S_IRUSR | S_IWUSR, sc->debug.debugfs_phy,
  			   &sc->tx.txq_max_pending[IEEE80211_AC_BK]);
  	debugfs_create_u32("qlen_be", S_IRUSR | S_IWUSR, sc->debug.debugfs_phy,

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: linux-next: manual merge of the driver-core tree with the net-next tree

[Greg KH]

On Thu, Aug 01, 2013 at 03:21:48PM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the driver-core tree got a conflict in
> net/core/net-sysfs.c between commit ff80e519ab1b ("net: export physical
> port id via sysfs") from the net-next tree and commit 6be8aeef348a ("net:
> core: convert class code to use dev_groups") from the driver-core tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Looks good to me, thanks.

greg k-h

linux-next: manual merge of the driver-core tree with the net-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 4226 bytes --]

Hi Greg,

Today's linux-next merge of the driver-core tree got a conflict in
net/core/net-sysfs.c between commit ff80e519ab1b ("net: export physical
port id via sysfs") from the net-next tree and commit 6be8aeef348a ("net:
core: convert class code to use dev_groups") from the driver-core tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc net/core/net-sysfs.c
index 8826b0d,707c313..0000000
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@@ -237,9 -250,9 +250,31 @@@ static ssize_t operstate_show(struct de
  
  	return sprintf(buf, "%s\n", operstates[operstate]);
  }
+ static DEVICE_ATTR_RO(operstate);
+ 
++static ssize_t phys_port_id_show(struct device *dev,
++				 struct device_attribute *attr, char *buf)
++{
++	struct net_device *netdev = to_net_dev(dev);
++	ssize_t ret = -EINVAL;
++
++	if (!rtnl_trylock())
++		return restart_syscall();
++
++	if (dev_isalive(netdev)) {
++		struct netdev_phys_port_id ppid;
++
++		ret = dev_get_phys_port_id(netdev, &ppid);
++		if (!ret)
++			ret = sprintf(buf, "%*phN\n", ppid.id_len, ppid.id);
++	}
++	rtnl_unlock();
++
++	return ret;
++}
++static DEVICE_ATTR_RO(phys_port_id);
 +
  /* read-write attributes */
- NETDEVICE_SHOW(mtu, fmt_dec);
  
  static int change_mtu(struct net_device *net, unsigned long new_mtu)
  {
@@@ -333,52 -344,32 +366,33 @@@ static ssize_t group_store(struct devic
  {
  	return netdev_store(dev, attr, buf, len, change_group);
  }
- 
- static ssize_t show_phys_port_id(struct device *dev,
- 				 struct device_attribute *attr, char *buf)
- {
- 	struct net_device *netdev = to_net_dev(dev);
- 	ssize_t ret = -EINVAL;
- 
- 	if (!rtnl_trylock())
- 		return restart_syscall();
- 
- 	if (dev_isalive(netdev)) {
- 		struct netdev_phys_port_id ppid;
- 
- 		ret = dev_get_phys_port_id(netdev, &ppid);
- 		if (!ret)
- 			ret = sprintf(buf, "%*phN\n", ppid.id_len, ppid.id);
- 	}
- 	rtnl_unlock();
- 
- 	return ret;
- }
- 
- static struct device_attribute net_class_attributes[] = {
- 	__ATTR(addr_assign_type, S_IRUGO, show_addr_assign_type, NULL),
- 	__ATTR(addr_len, S_IRUGO, show_addr_len, NULL),
- 	__ATTR(dev_id, S_IRUGO, show_dev_id, NULL),
- 	__ATTR(ifalias, S_IRUGO | S_IWUSR, show_ifalias, store_ifalias),
- 	__ATTR(iflink, S_IRUGO, show_iflink, NULL),
- 	__ATTR(ifindex, S_IRUGO, show_ifindex, NULL),
- 	__ATTR(type, S_IRUGO, show_type, NULL),
- 	__ATTR(link_mode, S_IRUGO, show_link_mode, NULL),
- 	__ATTR(address, S_IRUGO, show_address, NULL),
- 	__ATTR(broadcast, S_IRUGO, show_broadcast, NULL),
- 	__ATTR(carrier, S_IRUGO | S_IWUSR, show_carrier, store_carrier),
- 	__ATTR(speed, S_IRUGO, show_speed, NULL),
- 	__ATTR(duplex, S_IRUGO, show_duplex, NULL),
- 	__ATTR(dormant, S_IRUGO, show_dormant, NULL),
- 	__ATTR(operstate, S_IRUGO, show_operstate, NULL),
- 	__ATTR(mtu, S_IRUGO | S_IWUSR, show_mtu, store_mtu),
- 	__ATTR(flags, S_IRUGO | S_IWUSR, show_flags, store_flags),
- 	__ATTR(tx_queue_len, S_IRUGO | S_IWUSR, show_tx_queue_len,
- 	       store_tx_queue_len),
- 	__ATTR(netdev_group, S_IRUGO | S_IWUSR, show_group, store_group),
- 	__ATTR(phys_port_id, S_IRUGO, show_phys_port_id, NULL),
- 	{}
+ NETDEVICE_SHOW(group, fmt_dec);
+ static DEVICE_ATTR(netdev_group, S_IRUGO | S_IWUSR, group_show, group_store);
+ 
+ static struct attribute *net_class_attrs[] = {
+ 	&dev_attr_netdev_group.attr,
+ 	&dev_attr_type.attr,
+ 	&dev_attr_dev_id.attr,
+ 	&dev_attr_iflink.attr,
+ 	&dev_attr_ifindex.attr,
+ 	&dev_attr_addr_assign_type.attr,
+ 	&dev_attr_addr_len.attr,
+ 	&dev_attr_link_mode.attr,
+ 	&dev_attr_address.attr,
+ 	&dev_attr_broadcast.attr,
+ 	&dev_attr_speed.attr,
+ 	&dev_attr_duplex.attr,
+ 	&dev_attr_dormant.attr,
+ 	&dev_attr_operstate.attr,
++	&dev_attr_phys_port_id.attr,
+ 	&dev_attr_ifalias.attr,
+ 	&dev_attr_carrier.attr,
+ 	&dev_attr_mtu.attr,
+ 	&dev_attr_flags.attr,
+ 	&dev_attr_tx_queue_len.attr,
+ 	NULL,
  };
+ ATTRIBUTE_GROUPS(net_class);
  
  /* Show a given an attribute in the statistics group */
  static ssize_t netstat_show(const struct device *d,

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: linux-next: manual merge of the driver-core tree with the net-next tree

[Greg KH]

On Mon, Feb 04, 2013 at 03:38:31PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> Today's linux-next merge of the driver-core tree got a conflict in drivers/net/wan/Kconfig between commit a786a7c0ad44 ("wanrouter: completely decouple obsolete code from kernel") from the net-next tree and commit c9f1b39aee74 ("drivers/net/wan: remove depends on CONFIG_EXPERIMENTAL") from the driver-core tree.
> 
> The former removed part of the text changed by the latter, so I just did
> that (see below) and can carry the fix as necessary (no action is
> required).

That sounds fine to me, thanks.

greg k-h

linux-next: manual merge of the driver-core tree with the net-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3211 bytes --]

Hi Greg,

Today's linux-next merge of the driver-core tree got a conflict in drivers/net/wan/Kconfig between commit a786a7c0ad44 ("wanrouter: completely decouple obsolete code from kernel") from the net-next tree and commit c9f1b39aee74 ("drivers/net/wan: remove depends on CONFIG_EXPERIMENTAL") from the driver-core tree.

The former removed part of the text changed by the latter, so I just did
that (see below) and can carry the fix as necessary (no action is
required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc drivers/net/wan/Kconfig
index 0c077b0,c0cd88d..0000000
--- a/drivers/net/wan/Kconfig
+++ b/drivers/net/wan/Kconfig
@@@ -356,9 -356,63 +356,9 @@@ config SDL
  	  To compile this driver as a module, choose M here: the
  	  module will be called sdla.
  
 -# Wan router core.
 -config WAN_ROUTER_DRIVERS
 -	tristate "WAN router drivers"
 -	depends on WAN_ROUTER
 -	---help---
 -	  Connect LAN to WAN via Linux box.
 -
 -	  Select driver your card and remember to say Y to "Wan Router."
 -	  You will need the wan-tools package which is available from
 -	  <ftp://ftp.sangoma.com/>.
 -
 -	  Note that the answer to this question won't directly affect the
 -	  kernel except for how subordinate drivers may be built:
 -	  saying N will just cause the configurator to skip all
 -	  the questions about WAN router drivers.
 -
 -	  If unsure, say N.
 -
 -config CYCLADES_SYNC
 -	tristate "Cyclom 2X(tm) cards"
 -	depends on WAN_ROUTER_DRIVERS && (PCI || ISA)
 -	---help---
 -	  Cyclom 2X from Cyclades Corporation <http://www.avocent.com/> is an
 -	  intelligent multiprotocol WAN adapter with data transfer rates up to
 -	  512 Kbps. These cards support the X.25 and SNA related protocols.
 -
 -	  While no documentation is available at this time please grab the
 -	  wanconfig tarball in
 -	  <http://www.conectiva.com.br/~acme/cycsyn-devel/> (with minor changes
 -	  to make it compile with the current wanrouter include files; efforts
 -	  are being made to use the original package available at
 -	  <ftp://ftp.sangoma.com/>).
 -
 -	  Feel free to contact me or the cycsyn-devel mailing list at
 -	  <acme@conectiva.com.br> and <cycsyn-devel@bazar.conectiva.com.br> for
 -	  additional details, I hope to have documentation available as soon as
 -	  possible. (Cyclades Brazil is writing the Documentation).
 -
 -	  The next questions will ask you about the protocols you want the
 -	  driver to support (for now only X.25 is supported).
 -
 -	  If you have one or more of these cards, say Y to this option.
 -
 -	  To compile this driver as a module, choose M here: the
 -	  module will be called cyclomx.
 -
 -config CYCLOMX_X25
 -	bool "Cyclom 2X X.25 support"
 -	depends on CYCLADES_SYNC
 -	help
 -	  Connect a Cyclom 2X card to an X.25 network.
 -
 -	  Enabling X.25 support will enlarge your kernel by about 11 kB.
 -
  # X.25 network drivers
  config LAPBETHER
- 	tristate "LAPB over Ethernet driver (EXPERIMENTAL)"
+ 	tristate "LAPB over Ethernet driver"
  	depends on LAPB && X25
  	---help---
  	  Driver for a pseudo device (typically called /dev/lapb0) which allows

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the driver-core tree with the net-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 511 bytes --]

Hi Greg,

Today's linux-next merge of the driver-core tree got a conflict in
net/wanrouter/Kconfig between commit 6fcdf4facb85 ("wanrouter: delete now
orphaned header content, files/drivers") from the net-next tree and
commit 1ed42403e764 ("net/wanrouter: remove depends on
CONFIG_EXPERIMENTAL") from the driver-core tree.

The former removed the file, so I did that and can carry the fix as
necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

linux-next: manual merge of the driver-core tree with the net-next tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3516 bytes --]

Hi Greg,

Today's linux-next merge of the driver-core tree got a conflict in
fs/sysfs/dir.c between commit 23396180a977 ("sysfs: Remove support for
tagged directories with untagged members") from the net-next tree and
commits 4f72c0cab405 ("sysfs: use rb-tree for name lookups") and
a406f75840e1 ("sysfs: use rb-tree for inode number lookup") from the
driver-core tree.

I fixed it up (I think - see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc fs/sysfs/dir.c
index 26f370a,83bb9d1..0000000
--- a/fs/sysfs/dir.c
+++ b/fs/sysfs/dir.c
@@@ -547,22 -558,36 +565,43 @@@ struct sysfs_dirent *sysfs_find_dirent(
  				       const void *ns,
  				       const unsigned char *name)
  {
- 	struct sysfs_dirent *sd;
+ 	struct rb_node *p = parent_sd->s_dir.name_tree.rb_node;
+ 	struct sysfs_dirent *found = NULL;
  
 +	if (!!sysfs_ns_type(parent_sd) != !!ns) {
 +		WARN(1, KERN_WARNING "sysfs: ns %s in '%s' for '%s'\n",
 +			sysfs_ns_type(parent_sd)? "required": "invalid",
 +			parent_sd->s_name, name);
 +		return NULL;
 +	}
 +
- 	for (sd = parent_sd->s_dir.children; sd; sd = sd->s_sibling) {
- 		if (sd->s_ns != ns)
- 			continue;
- 		if (!strcmp(sd->s_name, name))
- 			return sd;
+ 	while (p) {
+ 		int c;
+ #define node	rb_entry(p, struct sysfs_dirent, name_node)
+ 		c = strcmp(name, node->s_name);
+ 		if (c < 0) {
+ 			p = node->name_node.rb_left;
+ 		} else if (c > 0) {
+ 			p = node->name_node.rb_right;
+ 		} else {
+ 			found = node;
+ 			p = node->name_node.rb_left;
+ 		}
+ #undef node
  	}
- 	return NULL;
+ 
+ 	if (found && ns) {
+ 		while (found->s_ns && found->s_ns != ns) {
+ 			p = rb_next(&found->name_node);
+ 			if (!p)
+ 				return NULL;
+ 			found = rb_entry(p, struct sysfs_dirent, name_node);
+ 			if (strcmp(name, found->s_name))
+ 				return NULL;
+ 		}
+ 	}
+ 
+ 	return found;
  }
  
  /**
@@@ -895,12 -918,28 +932,28 @@@ static struct sysfs_dirent *sysfs_dir_p
  			pos = NULL;
  	}
  	if (!pos && (ino > 1) && (ino < INT_MAX)) {
- 		pos = parent_sd->s_dir.children;
- 		while (pos && (ino > pos->s_ino))
- 			pos = pos->s_sibling;
+ 		struct rb_node *p = parent_sd->s_dir.inode_tree.rb_node;
+ 		while (p) {
+ #define node	rb_entry(p, struct sysfs_dirent, inode_node)
+ 			if (ino < node->s_ino) {
+ 				pos = node;
+ 				p = node->inode_node.rb_left;
+ 			} else if (ino > node->s_ino) {
+ 				p = node->inode_node.rb_right;
+ 			} else {
+ 				pos = node;
+ 				break;
+ 			}
+ #undef node
+ 		}
+ 	}
 -	while (pos && pos->s_ns && pos->s_ns != ns) {
++	while (pos && pos->s_ns != ns) {
+ 		struct rb_node *p = rb_next(&pos->inode_node);
+ 		if (!p)
+ 			pos = NULL;
+ 		else
+ 			pos = rb_entry(p, struct sysfs_dirent, inode_node);
  	}
- 	while (pos && pos->s_ns != ns)
- 		pos = pos->s_sibling;
  	return pos;
  }
  
@@@ -908,10 -947,13 +961,13 @@@ static struct sysfs_dirent *sysfs_dir_n
  	struct sysfs_dirent *parent_sd,	ino_t ino, struct sysfs_dirent *pos)
  {
  	pos = sysfs_dir_pos(ns, parent_sd, ino, pos);
- 	if (pos)
- 		pos = pos->s_sibling;
- 	while (pos && pos->s_ns != ns)
- 		pos = pos->s_sibling;
+ 	if (pos) do {
+ 		struct rb_node *p = rb_next(&pos->inode_node);
+ 		if (!p)
+ 			pos = NULL;
+ 		else
+ 			pos = rb_entry(p, struct sysfs_dirent, inode_node);
 -	} while (pos && pos->s_ns && pos->s_ns != ns);
++	} while (pos && pos->s_ns != ns);
  	return pos;
  }
  

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]