<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/firmware, branch v6.9.2</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>Merge tag 'soc-fixes-6.9-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc</title>
<updated>2024-05-08T17:15:40+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2024-05-08T17:15:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6d7ddd805123e03db0a16c7dbc8509366432a630'/>
<id>6d7ddd805123e03db0a16c7dbc8509366432a630</id>
<content type='text'>
Pull ARM SoC fixes from Arnd Bergmann:
 "These are a couple of last minute fixes that came in over the previous
  week, addressing:

   - A pin configuration bug on a qualcomm board that caused issues with
     ethernet and mmc

   - Two minor code fixes for misleading console output in the microchip
     firmware driver

   - A build warning in the sifive cache driver"

* tag 'soc-fixes-6.9-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc:
  firmware: microchip: clarify that sizes and addresses are in hex
  firmware: microchip: don't unconditionally print validation success
  arm64: dts: qcom: sa8155p-adp: fix SDHC2 CD pin configuration
  cache: sifive_ccache: Silence unused variable warning
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull ARM SoC fixes from Arnd Bergmann:
 "These are a couple of last minute fixes that came in over the previous
  week, addressing:

   - A pin configuration bug on a qualcomm board that caused issues with
     ethernet and mmc

   - Two minor code fixes for misleading console output in the microchip
     firmware driver

   - A build warning in the sifive cache driver"

* tag 'soc-fixes-6.9-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc:
  firmware: microchip: clarify that sizes and addresses are in hex
  firmware: microchip: don't unconditionally print validation success
  arm64: dts: qcom: sa8155p-adp: fix SDHC2 CD pin configuration
  cache: sifive_ccache: Silence unused variable warning
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'efi-urgent-for-v6.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi</title>
<updated>2024-05-03T19:05:19+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2024-05-03T19:05:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f094ee78e01f5ee08d9489b4250fa1963fef81ab'/>
<id>f094ee78e01f5ee08d9489b4250fa1963fef81ab</id>
<content type='text'>
Pull EFI fix from Ard Biesheuvel:
 "This works around a shortcoming in the memory acceptation API, which
  may apparently hog the CPU for long enough to trigger the softlockup
  watchdog.

  Note that this only affects confidential VMs running under the Intel
  TDX hypervisor, which is why I accepted this for now, but this should
  obviously be fixed properly in the future"

* tag 'efi-urgent-for-v6.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi:
  efi/unaccepted: touch soft lockup during memory accept
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull EFI fix from Ard Biesheuvel:
 "This works around a shortcoming in the memory acceptation API, which
  may apparently hog the CPU for long enough to trigger the softlockup
  watchdog.

  Note that this only affects confidential VMs running under the Intel
  TDX hypervisor, which is why I accepted this for now, but this should
  obviously be fixed properly in the future"

* tag 'efi-urgent-for-v6.9-1' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi:
  efi/unaccepted: touch soft lockup during memory accept
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'riscv-soc-fixes-for-v6.9-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into arm/fixes</title>
<updated>2024-04-30T10:31:22+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2024-04-30T10:31:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e845bcc8cfda6a1875dcf7e7d01c4e6791cc3f81'/>
<id>e845bcc8cfda6a1875dcf7e7d01c4e6791cc3f81</id>
<content type='text'>
RISC-V SoC driver fixes for v6.9-rc6

firmware:
Two changes for misleading printouts from the auto update driver, one
for an erroneous success message and the other to make it clear
addresses are in hex.

cache:
Samuel's fix for the ccache driver left an unused variable, so he
sent a follow up patch to silence that complaint.

Signed-off-by: Conor Dooley &lt;conor.dooley@microchip.com&gt;

* tag 'riscv-soc-fixes-for-v6.9-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux:
  firmware: microchip: clarify that sizes and addresses are in hex
  firmware: microchip: don't unconditionally print validation success
  cache: sifive_ccache: Silence unused variable warning

Link: https://lore.kernel.org/r/20240427-unflawed-humorless-690472f9c5a0@spud
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
RISC-V SoC driver fixes for v6.9-rc6

firmware:
Two changes for misleading printouts from the auto update driver, one
for an erroneous success message and the other to make it clear
addresses are in hex.

cache:
Samuel's fix for the ccache driver left an unused variable, so he
sent a follow up patch to silence that complaint.

Signed-off-by: Conor Dooley &lt;conor.dooley@microchip.com&gt;

* tag 'riscv-soc-fixes-for-v6.9-rc6' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux:
  firmware: microchip: clarify that sizes and addresses are in hex
  firmware: microchip: don't unconditionally print validation success
  cache: sifive_ccache: Silence unused variable warning

Link: https://lore.kernel.org/r/20240427-unflawed-humorless-690472f9c5a0@spud
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'qcom-drivers-fixes-for-6.9' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into for-next</title>
<updated>2024-04-26T16:08:02+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2024-04-26T16:08:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=14672a9b3ec5c934cf86658328a56207337b54ff'/>
<id>14672a9b3ec5c934cf86658328a56207337b54ff</id>
<content type='text'>
Qualcomm driver fix for v6.9

This reworks the memory layout of the argument buffers passed to trusted
applications in QSEECOM, to avoid failures and system crashes.

* tag 'qcom-drivers-fixes-for-6.9' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
  firmware: qcom: uefisecapp: Fix memory related IO errors and crashes

Link: https://lore.kernel.org/r/20240420163816.1133528-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Qualcomm driver fix for v6.9

This reworks the memory layout of the argument buffers passed to trusted
applications in QSEECOM, to avoid failures and system crashes.

* tag 'qcom-drivers-fixes-for-6.9' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
  firmware: qcom: uefisecapp: Fix memory related IO errors and crashes

Link: https://lore.kernel.org/r/20240420163816.1133528-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>firmware: microchip: clarify that sizes and addresses are in hex</title>
<updated>2024-04-24T21:02:20+00:00</updated>
<author>
<name>Conor Dooley</name>
<email>conor.dooley@microchip.com</email>
</author>
<published>2024-04-10T11:58:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3aa20d1f7bcb19a79b8062e49153eb3b16a88adb'/>
<id>3aa20d1f7bcb19a79b8062e49153eb3b16a88adb</id>
<content type='text'>
As it says on the tin. It can be kinda confusing when "22830" is in hex,
so prefix the hex numbers with a "0x".

Signed-off-by: Conor Dooley &lt;conor.dooley@microchip.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
As it says on the tin. It can be kinda confusing when "22830" is in hex,
so prefix the hex numbers with a "0x".

Signed-off-by: Conor Dooley &lt;conor.dooley@microchip.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>firmware: microchip: don't unconditionally print validation success</title>
<updated>2024-04-24T21:02:20+00:00</updated>
<author>
<name>Conor Dooley</name>
<email>conor.dooley@microchip.com</email>
</author>
<published>2024-04-10T11:58:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6e3b7e862ea4e4ff1be1d153ae07dfe150ed8896'/>
<id>6e3b7e862ea4e4ff1be1d153ae07dfe150ed8896</id>
<content type='text'>
If validation fails, both prints are made. Skip the success one in the
failure case.

Fixes: ec5b0f1193ad ("firmware: microchip: add PolarFire SoC Auto Update support")
Signed-off-by: Conor Dooley &lt;conor.dooley@microchip.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If validation fails, both prints are made. Skip the success one in the
failure case.

Fixes: ec5b0f1193ad ("firmware: microchip: add PolarFire SoC Auto Update support")
Signed-off-by: Conor Dooley &lt;conor.dooley@microchip.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>efi/unaccepted: touch soft lockup during memory accept</title>
<updated>2024-04-24T17:11:34+00:00</updated>
<author>
<name>Chen Yu</name>
<email>yu.c.chen@intel.com</email>
</author>
<published>2024-04-10T10:23:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1c5a1627f48105cbab81d25ec2f72232bfaa8185'/>
<id>1c5a1627f48105cbab81d25ec2f72232bfaa8185</id>
<content type='text'>
Commit 50e782a86c98 ("efi/unaccepted: Fix soft lockups caused by
parallel memory acceptance") has released the spinlock so other CPUs can
do memory acceptance in parallel and not triggers softlockup on other
CPUs.

However the softlock up was intermittent shown up if the memory of the
TD guest is large, and the timeout of softlockup is set to 1 second:

 RIP: 0010:_raw_spin_unlock_irqrestore
 Call Trace:
 ? __hrtimer_run_queues
 &lt;IRQ&gt;
 ? hrtimer_interrupt
 ? watchdog_timer_fn
 ? __sysvec_apic_timer_interrupt
 ? __pfx_watchdog_timer_fn
 ? sysvec_apic_timer_interrupt
 &lt;/IRQ&gt;
 ? __hrtimer_run_queues
 &lt;TASK&gt;
 ? hrtimer_interrupt
 ? asm_sysvec_apic_timer_interrupt
 ? _raw_spin_unlock_irqrestore
 ? __sysvec_apic_timer_interrupt
 ? sysvec_apic_timer_interrupt
 accept_memory
 try_to_accept_memory
 do_huge_pmd_anonymous_page
 get_page_from_freelist
 __handle_mm_fault
 __alloc_pages
 __folio_alloc
 ? __tdx_hypercall
 handle_mm_fault
 vma_alloc_folio
 do_user_addr_fault
 do_huge_pmd_anonymous_page
 exc_page_fault
 ? __do_huge_pmd_anonymous_page
 asm_exc_page_fault
 __handle_mm_fault

When the local irq is enabled at the end of accept_memory(), the
softlockup detects that the watchdog on single CPU has not been fed for
a while. That is to say, even other CPUs will not be blocked by
spinlock, the current CPU might be stunk with local irq disabled for a
while, which hurts not only nmi watchdog but also softlockup.

Chao Gao pointed out that the memory accept could be time costly and
there was similar report before. Thus to avoid any softlocup detection
during this stage, give the softlockup a flag to skip the timeout check
at the end of accept_memory(), by invoking touch_softlockup_watchdog().

Reported-by: Hossain, Md Iqbal &lt;md.iqbal.hossain@intel.com&gt;
Signed-off-by: Chen Yu &lt;yu.c.chen@intel.com&gt;
Reviewed-by: Kirill A. Shutemov &lt;kirill.shutemov@linux.intel.com&gt;
Fixes: 50e782a86c98 ("efi/unaccepted: Fix soft lockups caused by parallel memory acceptance")
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit 50e782a86c98 ("efi/unaccepted: Fix soft lockups caused by
parallel memory acceptance") has released the spinlock so other CPUs can
do memory acceptance in parallel and not triggers softlockup on other
CPUs.

However the softlock up was intermittent shown up if the memory of the
TD guest is large, and the timeout of softlockup is set to 1 second:

 RIP: 0010:_raw_spin_unlock_irqrestore
 Call Trace:
 ? __hrtimer_run_queues
 &lt;IRQ&gt;
 ? hrtimer_interrupt
 ? watchdog_timer_fn
 ? __sysvec_apic_timer_interrupt
 ? __pfx_watchdog_timer_fn
 ? sysvec_apic_timer_interrupt
 &lt;/IRQ&gt;
 ? __hrtimer_run_queues
 &lt;TASK&gt;
 ? hrtimer_interrupt
 ? asm_sysvec_apic_timer_interrupt
 ? _raw_spin_unlock_irqrestore
 ? __sysvec_apic_timer_interrupt
 ? sysvec_apic_timer_interrupt
 accept_memory
 try_to_accept_memory
 do_huge_pmd_anonymous_page
 get_page_from_freelist
 __handle_mm_fault
 __alloc_pages
 __folio_alloc
 ? __tdx_hypercall
 handle_mm_fault
 vma_alloc_folio
 do_user_addr_fault
 do_huge_pmd_anonymous_page
 exc_page_fault
 ? __do_huge_pmd_anonymous_page
 asm_exc_page_fault
 __handle_mm_fault

When the local irq is enabled at the end of accept_memory(), the
softlockup detects that the watchdog on single CPU has not been fed for
a while. That is to say, even other CPUs will not be blocked by
spinlock, the current CPU might be stunk with local irq disabled for a
while, which hurts not only nmi watchdog but also softlockup.

Chao Gao pointed out that the memory accept could be time costly and
there was similar report before. Thus to avoid any softlocup detection
during this stage, give the softlockup a flag to skip the timeout check
at the end of accept_memory(), by invoking touch_softlockup_watchdog().

Reported-by: Hossain, Md Iqbal &lt;md.iqbal.hossain@intel.com&gt;
Signed-off-by: Chen Yu &lt;yu.c.chen@intel.com&gt;
Reviewed-by: Kirill A. Shutemov &lt;kirill.shutemov@linux.intel.com&gt;
Fixes: 50e782a86c98 ("efi/unaccepted: Fix soft lockups caused by parallel memory acceptance")
Signed-off-by: Ard Biesheuvel &lt;ardb@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>firmware: qcom: uefisecapp: Fix memory related IO errors and crashes</title>
<updated>2024-04-09T15:05:03+00:00</updated>
<author>
<name>Maximilian Luz</name>
<email>luzmaximilian@gmail.com</email>
</author>
<published>2024-04-06T13:01:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ed09f81eeaa8f9265e1787282cb283f10285c259'/>
<id>ed09f81eeaa8f9265e1787282cb283f10285c259</id>
<content type='text'>
It turns out that while the QSEECOM APP_SEND command has specific fields
for request and response buffers, uefisecapp expects them both to be in
a single memory region. Failure to adhere to this has (so far) resulted
in either no response being written to the response buffer (causing an
EIO to be emitted down the line), the SCM call to fail with EINVAL
(i.e., directly from TZ/firmware), or the device to be hard-reset.

While this issue can be triggered deterministically, in the current form
it seems to happen rather sporadically (which is why it has gone
unnoticed during earlier testing). This is likely due to the two
kzalloc() calls (for request and response) being directly after each
other. Which means that those likely return consecutive regions most of
the time, especially when not much else is going on in the system.

Fix this by allocating a single memory region for both request and
response buffers, properly aligning both structs inside it. This
unfortunately also means that the qcom_scm_qseecom_app_send() interface
needs to be restructured, as it should no longer map the DMA regions
separately. Therefore, move the responsibility of DMA allocation (or
mapping) to the caller.

Fixes: 759e7a2b62eb ("firmware: Add support for Qualcomm UEFI Secure Application")
Cc: stable@vger.kernel.org  # 6.7
Tested-by: Johan Hovold &lt;johan+linaro@kernel.org&gt;
Reviewed-by: Johan Hovold &lt;johan+linaro@kernel.org&gt;
Signed-off-by: Maximilian Luz &lt;luzmaximilian@gmail.com&gt;
Tested-by: Konrad Dybcio &lt;konrad.dybcio@linaro.org&gt; # X13s
Link: https://lore.kernel.org/r/20240406130125.1047436-1-luzmaximilian@gmail.com
Signed-off-by: Bjorn Andersson &lt;andersson@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It turns out that while the QSEECOM APP_SEND command has specific fields
for request and response buffers, uefisecapp expects them both to be in
a single memory region. Failure to adhere to this has (so far) resulted
in either no response being written to the response buffer (causing an
EIO to be emitted down the line), the SCM call to fail with EINVAL
(i.e., directly from TZ/firmware), or the device to be hard-reset.

While this issue can be triggered deterministically, in the current form
it seems to happen rather sporadically (which is why it has gone
unnoticed during earlier testing). This is likely due to the two
kzalloc() calls (for request and response) being directly after each
other. Which means that those likely return consecutive regions most of
the time, especially when not much else is going on in the system.

Fix this by allocating a single memory region for both request and
response buffers, properly aligning both structs inside it. This
unfortunately also means that the qcom_scm_qseecom_app_send() interface
needs to be restructured, as it should no longer map the DMA regions
separately. Therefore, move the responsibility of DMA allocation (or
mapping) to the caller.

Fixes: 759e7a2b62eb ("firmware: Add support for Qualcomm UEFI Secure Application")
Cc: stable@vger.kernel.org  # 6.7
Tested-by: Johan Hovold &lt;johan+linaro@kernel.org&gt;
Reviewed-by: Johan Hovold &lt;johan+linaro@kernel.org&gt;
Signed-off-by: Maximilian Luz &lt;luzmaximilian@gmail.com&gt;
Tested-by: Konrad Dybcio &lt;konrad.dybcio@linaro.org&gt; # X13s
Link: https://lore.kernel.org/r/20240406130125.1047436-1-luzmaximilian@gmail.com
Signed-off-by: Bjorn Andersson &lt;andersson@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'ffa-fix-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes</title>
<updated>2024-04-09T14:29:48+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2024-04-09T14:29:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e349017a7b5c15c5ecf9f088434c45772c323bba'/>
<id>e349017a7b5c15c5ecf9f088434c45772c323bba</id>
<content type='text'>
Arm FF-A fix for v6.9

A single fix to address the incorrect check of VM ID count for the
global notification in the response received for FFA_NOTIFICATION_INFO_GET()
in the schedule receiver interrupt handler.

* tag 'ffa-fix-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
  firmware: arm_ffa: Fix the partition ID check in ffa_notification_info_get()

Link: https://lore.kernel.org/r/20240404140339.450509-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Arm FF-A fix for v6.9

A single fix to address the incorrect check of VM ID count for the
global notification in the response received for FFA_NOTIFICATION_INFO_GET()
in the schedule receiver interrupt handler.

* tag 'ffa-fix-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
  firmware: arm_ffa: Fix the partition ID check in ffa_notification_info_get()

Link: https://lore.kernel.org/r/20240404140339.450509-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'scmi-fixes-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes</title>
<updated>2024-04-09T14:22:19+00:00</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2024-04-09T14:22:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=64c80c99ed4a608aba516362e19e3bf5dffd36d7'/>
<id>64c80c99ed4a608aba516362e19e3bf5dffd36d7</id>
<content type='text'>
Arm SCMI fixes for v6.9

Couple of fixes to address wrong fastchannel initialization in powercap
protocol and disable seeking support for SCMI raw debugfs entries.

* tag 'scmi-fixes-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
  firmware: arm_scmi: Make raw debugfs entries non-seekable
  firmware: arm_scmi: Fix wrong fastchannel initialization

Link: https://lore.kernel.org/r/20240404140306.450330-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Arm SCMI fixes for v6.9

Couple of fixes to address wrong fastchannel initialization in powercap
protocol and disable seeking support for SCMI raw debugfs entries.

* tag 'scmi-fixes-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
  firmware: arm_scmi: Make raw debugfs entries non-seekable
  firmware: arm_scmi: Fix wrong fastchannel initialization

Link: https://lore.kernel.org/r/20240404140306.450330-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
</pre>
</div>
</content>
</entry>
</feed>
