<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/powerpc/sysdev, branch linux-3.18.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.18.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.18.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2018-09-26T06:33:51Z</updated>
<entry>
<title>powerpc: Fix size calculation using resource_size()</title>
<updated>2018-09-26T06:33:51Z</updated>
<author>
<name>Dan Carpenter</name>
</author>
<published>2018-08-08T11:57:24Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f0d26e4807275d45e9e01b35b5071f3824107f29'/>
<id>urn:sha1:f0d26e4807275d45e9e01b35b5071f3824107f29</id>
<content type='text'>
[ Upstream commit c42d3be0c06f0c1c416054022aa535c08a1f9b39 ]

The problem is the the calculation should be "end - start + 1" but the
plus one is missing in this calculation.

Fixes: 8626816e905e ("powerpc: add support for MPIC message register API")
Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Reviewed-by: Tyrel Datwyler &lt;tyreld@linux.vnet.ibm.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>powerpc/mpic: Check if cpu_possible() in mpic_physmask()</title>
<updated>2018-05-30T05:47:40Z</updated>
<author>
<name>Michael Ellerman</name>
</author>
<published>2018-03-30T12:27:25Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1699271ab466e92757fb895d567c959181cfa290'/>
<id>urn:sha1:1699271ab466e92757fb895d567c959181cfa290</id>
<content type='text'>
[ Upstream commit 0834d627fbea00c1444075eb3e448e1974da452d ]

In mpic_physmask() we loop over all CPUs up to 32, then get the hard
SMP processor id of that CPU.

Currently that's possibly walking off the end of the paca array, but
in a future patch we will change the paca array to be an array of
pointers, and in that case we will get a NULL for missing CPUs and
oops. eg:

  Unable to handle kernel paging request for data at address 0x88888888888888b8
  Faulting instruction address: 0xc00000000004e380
  Oops: Kernel access of bad area, sig: 11 [#1]
  ...
  NIP .mpic_set_affinity+0x60/0x1a0
  LR  .irq_do_set_affinity+0x48/0x100

Fix it by checking the CPU is possible, this also fixes the code if
there are gaps in the CPU numbering which probably never happens on
mpic systems but who knows.

Debugged-by: Nicholas Piggin &lt;npiggin@gmail.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>powerpc/ipic: Fix status get and status clear</title>
<updated>2017-12-20T09:01:32Z</updated>
<author>
<name>Christophe Leroy</name>
</author>
<published>2017-10-18T09:16:47Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=55bae20a7382543719207c84bf9e17487777ced8'/>
<id>urn:sha1:55bae20a7382543719207c84bf9e17487777ced8</id>
<content type='text'>
[ Upstream commit 6b148a7ce72a7f87c81cbcde48af014abc0516a9 ]

IPIC Status is provided by register IPIC_SERSR and not by IPIC_SERMR
which is the mask register.

Signed-off-by: Christophe Leroy &lt;christophe.leroy@c-s.fr&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>axonram: Fix gendisk handling</title>
<updated>2017-12-16T09:32:29Z</updated>
<author>
<name>Jan Kara</name>
</author>
<published>2017-03-08T13:56:05Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=8364904c104570a76045b23e78cbb438750a3c7e'/>
<id>urn:sha1:8364904c104570a76045b23e78cbb438750a3c7e</id>
<content type='text'>
[ Upstream commit 672a2c87c83649fb0167202342ce85af9a3b4f1c ]

It is invalid to call del_gendisk() when disk-&gt;queue is NULL. Fix error
handling in axon_ram_probe() to avoid doing that.

Also del_gendisk() does not drop a reference to gendisk allocated by
alloc_disk(). That has to be done by put_disk(). Add that call where
needed.

Reported-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Jens Axboe &lt;axboe@fb.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@verizon.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>powerpc/MSI: Fix race condition in tearing down MSI interrupts</title>
<updated>2015-10-28T02:14:14Z</updated>
<author>
<name>Paul Mackerras</name>
</author>
<published>2015-09-10T04:36:21Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5b12405cd01699eb0ac6784fb3cd9fb53e80dfd7'/>
<id>urn:sha1:5b12405cd01699eb0ac6784fb3cd9fb53e80dfd7</id>
<content type='text'>
[ Upstream commit e297c939b745e420ef0b9dc989cb87bda617b399 ]

This fixes a race which can result in the same virtual IRQ number
being assigned to two different MSI interrupts.  The most visible
consequence of that is usually a warning and stack trace from the
sysfs code about an attempt to create a duplicate entry in sysfs.

The race happens when one CPU (say CPU 0) is disposing of an MSI
while another CPU (say CPU 1) is setting up an MSI.  CPU 0 calls
(for example) pnv_teardown_msi_irqs(), which calls
msi_bitmap_free_hwirqs() to indicate that the MSI (i.e. its
hardware IRQ number) is no longer in use.  Then, before CPU 0 gets
to calling irq_dispose_mapping() to free up the virtal IRQ number,
CPU 1 comes in and calls msi_bitmap_alloc_hwirqs() to allocate an
MSI, and gets the same hardware IRQ number that CPU 0 just freed.
CPU 1 then calls irq_create_mapping() to get a virtual IRQ number,
which sees that there is currently a mapping for that hardware IRQ
number and returns the corresponding virtual IRQ number (which is
the same virtual IRQ number that CPU 0 was using).  CPU 0 then
calls irq_dispose_mapping() and frees that virtual IRQ number.
Now, if another CPU comes along and calls irq_create_mapping(), it
is likely to get the virtual IRQ number that was just freed,
resulting in the same virtual IRQ number apparently being used for
two different hardware interrupts.

To fix this race, we just move the call to msi_bitmap_free_hwirqs()
to after the call to irq_dispose_mapping().  Since virq_to_hw()
doesn't work for the virtual IRQ number after irq_dispose_mapping()
has been called, we need to call it before irq_dispose_mapping() and
remember the result for the msi_bitmap_free_hwirqs() call.

The pattern of calling msi_bitmap_free_hwirqs() before
irq_dispose_mapping() appears in 5 places under arch/powerpc, and
appears to have originated in commit 05af7bd2d75e ("[POWERPC] MPIC
U3/U4 MSI backend") from 2007.

Fixes: 05af7bd2d75e ("[POWERPC] MPIC U3/U4 MSI backend")
Cc: stable@vger.kernel.org # v2.6.22+
Reported-by: Alexey Kardashevskiy &lt;aik@ozlabs.ru&gt;
Signed-off-by: Paul Mackerras &lt;paulus@samba.org&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Signed-off-by: Sasha Levin &lt;sasha.levin@oracle.com&gt;
</content>
</entry>
<entry>
<title>axonram: Fix bug in direct_access</title>
<updated>2015-03-06T22:52:59Z</updated>
<author>
<name>Matthew Wilcox</name>
</author>
<published>2015-01-07T16:04:18Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=532f6e6ffde28d2fc96993cf95161f2b35c9a6e3'/>
<id>urn:sha1:532f6e6ffde28d2fc96993cf95161f2b35c9a6e3</id>
<content type='text'>
commit 91117a20245b59f70b563523edbf998a62fc6383 upstream.

The 'pfn' returned by axonram was completely bogus, and has been since
2008.

Signed-off-by: Matthew Wilcox &lt;matthew.r.wilcox@intel.com&gt;
Reviewed-by: Jan Kara &lt;jack@suse.cz&gt;
Reviewed-by: Mathieu Desnoyers &lt;mathieu.desnoyers@efficios.com&gt;
Signed-off-by: Jens Axboe &lt;axboe@fb.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>powerpc/fsl_msi: mark the msi cascade handler IRQF_NO_THREAD</title>
<updated>2014-11-18T04:00:30Z</updated>
<author>
<name>Kevin Hao</name>
</author>
<published>2014-11-14T05:51:22Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=d7ce4377494adfaf8afb15ecf4f07d399bbf13d9'/>
<id>urn:sha1:d7ce4377494adfaf8afb15ecf4f07d399bbf13d9</id>
<content type='text'>
The commit 543c043cbae7 ("powerpc/fsl_msi: change the irq handler from
chained to normal") changes the msi cascade handler from chained to
normal. Since cascade handler must run in hard interrupt context, this
will cause kernel panic if we force threading of all the interrupt
handler via kernel command parameter 'threadirqs'. So mark the irq
handler IRQF_NO_THREAD explicitly.

Signed-off-by: Kevin Hao &lt;haokexin@gmail.com&gt;
Signed-off-by: Scott Wood &lt;scottwood@freescale.com&gt;
</content>
</entry>
<entry>
<title>Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux</title>
<updated>2014-10-21T14:48:56Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2014-10-21T14:48:56Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=dc303408a716e865099fcb3f83a90d9c51184c02'/>
<id>urn:sha1:dc303408a716e865099fcb3f83a90d9c51184c02</id>
<content type='text'>
Pull more powerpc updates from Michael Ellerman:
 "Here's some more updates for powerpc for 3.18.

  They are a bit late I know, though must are actually bug fixes.  In my
  defence I nearly cut the top of my finger off last weekend in a
  gruesome bike maintenance accident, so I spent a good part of the week
  waiting around for doctors.  True story, I can send photos if you like :)

  Probably the most interesting fix is the sys_call_table one, which
  enables syscall tracing for powerpc.  There's a fix for HMI handling
  for old firmware, more endian fixes for firmware interfaces, more EEH
  fixes, Anton fixed our routine that gets the current stack pointer,
  and a few other misc bits"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux: (22 commits)
  powerpc: Only do dynamic DMA zone limits on platforms that need it
  powerpc: sync pseries_le_defconfig with pseries_defconfig
  powerpc: Add printk levels to setup_system output
  powerpc/vphn: NUMA node code expects big-endian
  powerpc/msi: Use WARN_ON() in msi bitmap selftests
  powerpc/msi: Fix the msi bitmap alignment tests
  powerpc/eeh: Block CFG upon frozen Shiner adapter
  powerpc/eeh: Don't collect logs on PE with blocked config space
  powerpc/eeh: Block PCI config access upon frozen PE
  powerpc/pseries: Drop config requests in EEH accessors
  powerpc/powernv: Drop config requests in EEH accessors
  powerpc/eeh: Rename flag EEH_PE_RESET to EEH_PE_CFG_BLOCKED
  powerpc/eeh: Fix condition for isolated state
  powerpc/pseries: Make CPU hotplug path endian safe
  powerpc/pseries: Use dump_stack instead of show_stack
  powerpc: Rename __get_SP() to current_stack_pointer()
  powerpc: Reimplement __get_SP() as a function not a define
  powerpc/numa: Add ability to disable and debug topology updates
  powerpc/numa: check error return from proc_create
  powerpc/powernv: Fallback to old HMI handling behavior for old firmware
  ...
</content>
</entry>
<entry>
<title>powerpc/msi: Use WARN_ON() in msi bitmap selftests</title>
<updated>2014-10-15T02:09:33Z</updated>
<author>
<name>Michael Ellerman</name>
</author>
<published>2014-10-10T08:04:25Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4a77f2bdbdef289a02bd02fac483a9350e039705'/>
<id>urn:sha1:4a77f2bdbdef289a02bd02fac483a9350e039705</id>
<content type='text'>
As demonstrated in the previous commit, the failure message from the msi
bitmap selftests is a bit subtle, it's easy to miss a failure in a busy
boot log.

So drop our check() macro and use WARN_ON() instead. This necessitates
inverting all the conditions as well.

Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
</content>
</entry>
<entry>
<title>powerpc/msi: Fix the msi bitmap alignment tests</title>
<updated>2014-10-15T02:09:32Z</updated>
<author>
<name>Michael Ellerman</name>
</author>
<published>2014-10-10T08:04:24Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=695911fb1f0e00aebe6c5636b9c08bf0fd51a2fd'/>
<id>urn:sha1:695911fb1f0e00aebe6c5636b9c08bf0fd51a2fd</id>
<content type='text'>
When we added the alignment tests recently we failed to check they were
actually passing - oops.

They weren't passing, because the bitmap was full. We should also be a
bit more careful when checking the return code, a negative error return
could by divisible by our alignment value.

Fixes: b0345bbc6d09 ("powerpc/msi: Improve IRQ bitmap allocator")
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
</content>
</entry>
</feed>
