On Aug 26, 2013, at 4:15 PM, "Maloy, Joe" <Joe.Maloy@xxxxxxx> wrote: > Chris, > > I would appreciate you toning down your rhetoric. Please keep it professional. > > What Sumit reported is correct. We are polling our Marketing and Product management organizations to see if we want to productize this type of support in our MR Linux drivers. We would not submit upstream changes that have not been successfully tested by our PT test org based on a GCA (general customer availability) or async release effort. Professionally speaking, however, having the megaraid_sas driver support big-endian is inline with the requirements of the driver being in the kernel tree to begin with. This support was promised 8 years back by LSI. Quite frankly, I can't imagine that LSI has to approve of this support before it can be included into the kernel proper. If LSI doesn't want to support big-endian, that's fine with me. However, if the community wants to support it in a public driver, I don't think LSIs Product Management and Marketing teams have anything useful to say about it. a) This driver doesn't work on big-endian b) This patch supports more architectures c) This patch doesn't break existing architecture support (not even that which LSI wants to support) Not including this patch does nothing useful. Including it will put megaraid_sas on the path to doing what every driver in the tree either does or attempts to do, and more important, should do. Historically, waiting on commercial upstream to deliver what the community has already done is wasted time. Likewise, historically, allowing patches that partially implement things (in this respect, support one generation of card for megaraid_sas) leads to further support from the community, in a much faster timeframe. -- Servergy : http://www.servergy.com/ SwissDisk : http://www.swissdisk.com/ Ubuntu : http://www.ubuntu.com/ My Blog : http://ben-collins.blogspot.com/
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
