Re: [GIT PULL] xhci: Big-endian sparse fixes.
On Wed, Nov 27, 2013 at 03:49:43PM -0800, Sarah Sharp wrote: On Wed, Nov 27, 2013 at 03:36:56PM -0800, Greg Kroah-Hartman wrote: On Wed, Nov 27, 2013 at 03:36:02PM -0800, Greg Kroah-Hartman wrote: On Wed, Nov 27, 2013 at 03:14:40PM -0800, Sarah Sharp wrote: The following changes since commit 7d49f0bac41ee9b012af1efe2f725d91a87a8fe9: USB: Maintainers change for usb serial drivers (2013-10-31 08:53:52 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git tags/for-usb-linus-2013-11-27 for you to fetch changes up to 172a894f74e090f3aada7b0347d334ad9db14a36: xhci: fix incorrect type in assignment in xhci_address_device() (2013-11-18 10:10:13 -0800) xhci: Big-endian sparse fixes. Hi Greg, Here's five sparse cleanups that make the xHCI driver actually work on big-endian machines. They're all marked for stable. Why is a new feature like big-endian support for xhci a stable thing? It's not a new feature. The xHCI driver has supported big-endian systems for ages (since 3.0 I think). There were several xHCI structures that had variables marked with __le32 to make sure the driver continued to work on big-endian systems. However, I was lax, and code got into 3.4 and 3.12 that broke the driver under big endian systems. Sparse found those issues, and Xenia cleaned them up. And something that isn't ok for 3.13-final? Wait, sorry, this is for 3.13-final? These are fixes to be queued for 3.13. totally confused. And if it is, is this a regression? It looks like a new feature to me. Yes, it's a regression that has been there since 3.4. No one complained about it since then, so I seriously considered whether they should go into stable or not. Does that explanation make sense? Bah, this is not worth arguing about. I have a more important regression to fix to get into 3.13, so I'll send you a second pull request with all these patches queued for usb-next. Sarah Sharp -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] xhci: Big-endian sparse fixes.
On Mon, Dec 02, 2013 at 10:40:48AM -0800, Sarah Sharp wrote: On Wed, Nov 27, 2013 at 03:49:43PM -0800, Sarah Sharp wrote: On Wed, Nov 27, 2013 at 03:36:56PM -0800, Greg Kroah-Hartman wrote: On Wed, Nov 27, 2013 at 03:36:02PM -0800, Greg Kroah-Hartman wrote: On Wed, Nov 27, 2013 at 03:14:40PM -0800, Sarah Sharp wrote: The following changes since commit 7d49f0bac41ee9b012af1efe2f725d91a87a8fe9: USB: Maintainers change for usb serial drivers (2013-10-31 08:53:52 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git tags/for-usb-linus-2013-11-27 for you to fetch changes up to 172a894f74e090f3aada7b0347d334ad9db14a36: xhci: fix incorrect type in assignment in xhci_address_device() (2013-11-18 10:10:13 -0800) xhci: Big-endian sparse fixes. Hi Greg, Here's five sparse cleanups that make the xHCI driver actually work on big-endian machines. They're all marked for stable. Why is a new feature like big-endian support for xhci a stable thing? It's not a new feature. The xHCI driver has supported big-endian systems for ages (since 3.0 I think). There were several xHCI structures that had variables marked with __le32 to make sure the driver continued to work on big-endian systems. However, I was lax, and code got into 3.4 and 3.12 that broke the driver under big endian systems. Sparse found those issues, and Xenia cleaned them up. And something that isn't ok for 3.13-final? Wait, sorry, this is for 3.13-final? These are fixes to be queued for 3.13. totally confused. And if it is, is this a regression? It looks like a new feature to me. Yes, it's a regression that has been there since 3.4. No one complained about it since then, so I seriously considered whether they should go into stable or not. Does that explanation make sense? Bah, this is not worth arguing about. I have a more important regression to fix to get into 3.13, so I'll send you a second pull request with all these patches queued for usb-next. Ok, consider this one dropped. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] xhci: Big-endian sparse fixes.
On Wed, Nov 27, 2013 at 03:14:40PM -0800, Sarah Sharp wrote: The following changes since commit 7d49f0bac41ee9b012af1efe2f725d91a87a8fe9: USB: Maintainers change for usb serial drivers (2013-10-31 08:53:52 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git tags/for-usb-linus-2013-11-27 for you to fetch changes up to 172a894f74e090f3aada7b0347d334ad9db14a36: xhci: fix incorrect type in assignment in xhci_address_device() (2013-11-18 10:10:13 -0800) xhci: Big-endian sparse fixes. Hi Greg, Here's five sparse cleanups that make the xHCI driver actually work on big-endian machines. They're all marked for stable. Why is a new feature like big-endian support for xhci a stable thing? And something that isn't ok for 3.13-final? You can't have it both ways, sorry. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] xhci: Big-endian sparse fixes.
On Wed, Nov 27, 2013 at 03:36:02PM -0800, Greg Kroah-Hartman wrote: On Wed, Nov 27, 2013 at 03:14:40PM -0800, Sarah Sharp wrote: The following changes since commit 7d49f0bac41ee9b012af1efe2f725d91a87a8fe9: USB: Maintainers change for usb serial drivers (2013-10-31 08:53:52 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git tags/for-usb-linus-2013-11-27 for you to fetch changes up to 172a894f74e090f3aada7b0347d334ad9db14a36: xhci: fix incorrect type in assignment in xhci_address_device() (2013-11-18 10:10:13 -0800) xhci: Big-endian sparse fixes. Hi Greg, Here's five sparse cleanups that make the xHCI driver actually work on big-endian machines. They're all marked for stable. Why is a new feature like big-endian support for xhci a stable thing? And something that isn't ok for 3.13-final? Wait, sorry, this is for 3.13-final? totally confused. And if it is, is this a regression? It looks like a new feature to me. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] xhci: Big-endian sparse fixes.
On Wed, Nov 27, 2013 at 03:36:56PM -0800, Greg Kroah-Hartman wrote: On Wed, Nov 27, 2013 at 03:36:02PM -0800, Greg Kroah-Hartman wrote: On Wed, Nov 27, 2013 at 03:14:40PM -0800, Sarah Sharp wrote: The following changes since commit 7d49f0bac41ee9b012af1efe2f725d91a87a8fe9: USB: Maintainers change for usb serial drivers (2013-10-31 08:53:52 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git tags/for-usb-linus-2013-11-27 for you to fetch changes up to 172a894f74e090f3aada7b0347d334ad9db14a36: xhci: fix incorrect type in assignment in xhci_address_device() (2013-11-18 10:10:13 -0800) xhci: Big-endian sparse fixes. Hi Greg, Here's five sparse cleanups that make the xHCI driver actually work on big-endian machines. They're all marked for stable. Why is a new feature like big-endian support for xhci a stable thing? It's not a new feature. The xHCI driver has supported big-endian systems for ages (since 3.0 I think). There were several xHCI structures that had variables marked with __le32 to make sure the driver continued to work on big-endian systems. However, I was lax, and code got into 3.4 and 3.12 that broke the driver under big endian systems. Sparse found those issues, and Xenia cleaned them up. And something that isn't ok for 3.13-final? Wait, sorry, this is for 3.13-final? These are fixes to be queued for 3.13. totally confused. And if it is, is this a regression? It looks like a new feature to me. Yes, it's a regression that has been there since 3.4. No one complained about it since then, so I seriously considered whether they should go into stable or not. Does that explanation make sense? Sarah Sharp -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
