On Fri, 2015-01-09 at 18:21 +0100, Wolfram Sang wrote:
The number of I2C adapters which are not fully I2C compatible is rising,
sadly. Drivers usually do handle the flaws, still the user receives only
some errno for a transfer which normally can be expected to work. This
patch introduces a
On 01/16/2015 08:34 AM, Michael Ellerman wrote:
On Fri, 2015-01-16 at 13:28 +1300, Alexey Kardashevskiy wrote:
On 01/16/2015 02:22 AM, Preeti U Murthy wrote:
Hi Alexey,
Can you let me know if the following patch fixes the issue for you ?
It did for us on one of our machines that we were
On 01/16/2015 02:26 PM, Preeti U Murthy wrote:
On 01/16/2015 08:34 AM, Michael Ellerman wrote:
On Fri, 2015-01-16 at 13:28 +1300, Alexey Kardashevskiy wrote:
On 01/16/2015 02:22 AM, Preeti U Murthy wrote:
Hi Alexey,
Can you let me know if the following patch fixes the issue for you ?
It did
Am 16.01.2015 um 00:09 schrieb Michael Ellerman:
On Thu, 2015-01-15 at 09:58 +0100, Christian Borntraeger wrote:
ACCESS_ONCE does not work reliably on non-scalar types. For
example gcc 4.6 and 4.7 might remove the volatile tag for such
accesses during the SRA (scalar replacement of aggregates)
On 16/01/2015 04:02, Michael Ellerman wrote:
On Thu, 2015-01-15 at 15:41 -0800, Tyrel Datwyler wrote:
On 01/15/2015 02:19 PM, Michael Ellerman wrote:
If this was on a powerkvm guest set-indicator should be present for
hotplug (DLPAR) support. However, the surveillance indicator would not
be
On 15.01.15 09:58, Christian Borntraeger wrote:
Folks,
fyi, this is my current patch queue for the next merge window. It
does contain a patch that will disallow ACCESS_ONCE on non-scalar
types.
The tree is part of linux-next and can be found at
On 01/15/2015 03:58 AM, Michael Ellerman wrote:
On Wed, 2015-01-14 at 23:35 +0530, Hari Bathini wrote:
On 01/14/2015 10:01 AM, Michael Ellerman wrote:
On Wed, 2014-12-24 at 17:28 +0530, Hari Bathini wrote:
With minor checks, we can move most of the code for nvram
under pseries to a common
On 01/15/2015 11:15 PM, Ian Munsie wrote:
Hi Ryan,
Excerpts from Ryan Grimm's message of 2015-01-16 09:27:15 +1100:
reset_image_select identifies whether a PERST will cause the image to be
s/reset_image_select/load_image_on_perst/
Ah, thanks, fixed.
+What:
On 01/15/2015 11:27 PM, Ian Munsie wrote:
Hi Ryan,
Excerpts from Ryan Grimm's message of 2015-01-16 09:27:17 +1100:
Adds reset to sysfs which will PERST the card. If load_image_on_perst is set
to user or factory, the PERST will cause that image to be loaded.
load_image_on_perst is set to
Select defaults such that a PERST causes flash image reload. Select which
image based on what the card is set up to load.
CXL_VSEC_PERST_LOADS_IMAGE selects whether PERST assertion causes flash image
load.
CXL_VSEC_PERST_SELECT_USER selects which image is loaded on the next PERST.
load_image_on_perst identifies whether a PERST will cause the image to be
flashed to the card. And if so, which image.
Valid entries are: none, user and factory.
A value of none means PERST will not cause the image to be flashed. A power
cycle to the pcie slot is required to load the image.
Turning snoops on is the last step in CAPP recovery. Sapphire is expected to
have reinitialized the PHB and done the previous recovery steps.
Add mode argument to opal call to do this. Driver can turn snoops off although
it does not currently.
Signed-off-by: Ryan Grimm gr...@linux.vnet.ibm.com
Adds reset to sysfs which will PERST the card. If load_image_on_perst is set
to user or factory, the PERST will cause that image to be loaded.
load_image_on_perst is set to user for production.
none could be used for debugging. The PSL trace arrays are preserved which
then can be read through
13 matches
Mail list logo