<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git, branch v4.14.168</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.168</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.168'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2020-01-27T13:46:54+00:00</updated>
<entry>
<title>Linux 4.14.168</title>
<updated>2020-01-27T13:46:54+00:00</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2020-01-27T13:46:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9a95f25269bd9257ab9fba7bb14355d50b5f39ec'/>
<id>urn:sha1:9a95f25269bd9257ab9fba7bb14355d50b5f39ec</id>
<content type='text'>
</content>
</entry>
<entry>
<title>m68k: Call timer_interrupt() with interrupts disabled</title>
<updated>2020-01-27T13:46:54+00:00</updated>
<author>
<name>Finn Thain</name>
<email>fthain@telegraphics.com.au</email>
</author>
<published>2018-12-01T00:53:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4127249099b796b1fd5c74562ce94b94cda38553'/>
<id>urn:sha1:4127249099b796b1fd5c74562ce94b94cda38553</id>
<content type='text'>
[ Upstream commit 1efdd4bd254311498123a15fa0acd565f454da97 ]

Some platforms execute their timer handler with the interrupt priority
level set below 6. That means the handler could be interrupted by another
driver and this could lead to re-entry of the timer core.

Avoid this by use of local_irq_save/restore for timer interrupt dispatch.
This provides mutual exclusion around the timer interrupt flag access
which is needed later in this series for the clocksource conversion.

Reported-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Link: http://lkml.kernel.org/r/alpine.DEB.2.21.1811131407120.2697@nanos.tec.linutronix.de
Signed-off-by: Finn Thain &lt;fthain@telegraphics.com.au&gt;
Signed-off-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>serial: stm32: fix clearing interrupt error flags</title>
<updated>2020-01-27T13:46:53+00:00</updated>
<author>
<name>Fabrice Gasnier</name>
<email>fabrice.gasnier@st.com</email>
</author>
<published>2019-11-21T08:10:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7c662630d94fc07da206a8423bfbf9c2330bb2c8'/>
<id>urn:sha1:7c662630d94fc07da206a8423bfbf9c2330bb2c8</id>
<content type='text'>
[ Upstream commit 1250ed7114a977cdc2a67a0c09d6cdda63970eb9 ]

The interrupt clear flag register is a "write 1 to clear" register.
So, only writing ones allows to clear flags:
- Replace buggy stm32_clr_bits() by a simple write to clear error flags
- Replace useless read/modify/write stm32_set_bits() routine by a
  simple write to clear TC (transfer complete) flag.

Fixes: 4f01d833fdcd ("serial: stm32: fix rx error handling")
Signed-off-by: Fabrice Gasnier &lt;fabrice.gasnier@st.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Link: https://lore.kernel.org/r/1574323849-1909-1-git-send-email-fabrice.gasnier@st.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>IB/iser: Fix dma_nents type definition</title>
<updated>2020-01-27T13:46:53+00:00</updated>
<author>
<name>Max Gurtovoy</name>
<email>maxg@mellanox.com</email>
</author>
<published>2019-02-26T10:22:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=30987a4fd901be1a688feaf4b672d825ceffcd1c'/>
<id>urn:sha1:30987a4fd901be1a688feaf4b672d825ceffcd1c</id>
<content type='text'>
[ Upstream commit c1545f1a200f4adc4ef8dd534bf33e2f1aa22c2f ]

The retured value from ib_dma_map_sg saved in dma_nents variable. To avoid
future mismatch between types, define dma_nents as an integer instead of
unsigned.

Fixes: 57b26497fabe ("IB/iser: Pass the correct number of entries for dma mapped SGL")
Reported-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Reviewed-by: Israel Rukshin &lt;israelr@mellanox.com&gt;
Signed-off-by: Max Gurtovoy &lt;maxg@mellanox.com&gt;
Acked-by: Sagi Grimberg &lt;sagi@grimberg.me&gt;
Reviewed-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Jason Gunthorpe &lt;jgg@mellanox.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>arm64: dts: juno: Fix UART frequency</title>
<updated>2020-01-27T13:46:53+00:00</updated>
<author>
<name>Andre Przywara</name>
<email>andre.przywara@arm.com</email>
</author>
<published>2019-11-19T12:03:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=602cfd269e9cf2fa1c2242985ac0406834389402'/>
<id>urn:sha1:602cfd269e9cf2fa1c2242985ac0406834389402</id>
<content type='text'>
[ Upstream commit 39a1a8941b27c37f79508426e27a2ec29829d66c ]

Older versions of the Juno *SoC* TRM [1] recommended that the UART clock
source should be 7.2738 MHz, whereas the *system* TRM [2] stated a more
correct value of 7.3728 MHz. Somehow the wrong value managed to end up in
our DT.

Doing a prime factorisation, a modulo divide by 115200 and trying
to buy a 7.2738 MHz crystal at your favourite electronics dealer suggest
that the old value was actually a typo. The actual UART clock is driven
by a PLL, configured via a parameter in some board.txt file in the
firmware, which reads 7.37 MHz (sic!).

Fix this to correct the baud rate divisor calculation on the Juno board.

[1] http://infocenter.arm.com/help/topic/com.arm.doc.ddi0515b.b/DDI0515B_b_juno_arm_development_platform_soc_trm.pdf
[2] http://infocenter.arm.com/help/topic/com.arm.doc.100113_0000_07_en/arm_versatile_express_juno_development_platform_(v2m_juno)_technical_reference_manual_100113_0000_07_en.pdf

Fixes: 71f867ec130e ("arm64: Add Juno board device tree.")
Signed-off-by: Andre Przywara &lt;andre.przywara@arm.com&gt;
Acked-by: Liviu Dudau &lt;liviu.dudau@arm.com&gt;
Signed-off-by: Sudeep Holla &lt;sudeep.holla@arm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/radeon: fix bad DMA from INTERRUPT_CNTL2</title>
<updated>2020-01-27T13:46:53+00:00</updated>
<author>
<name>Sam Bobroff</name>
<email>sbobroff@linux.ibm.com</email>
</author>
<published>2019-11-17T23:53:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=75262c4cc870f6ccf29d33d8758a826dc735e3cf'/>
<id>urn:sha1:75262c4cc870f6ccf29d33d8758a826dc735e3cf</id>
<content type='text'>
[ Upstream commit 62d91dd2851e8ae2ca552f1b090a3575a4edf759 ]

The INTERRUPT_CNTL2 register expects a valid DMA address, but is
currently set with a GPU MC address.  This can cause problems on
systems that detect the resulting DMA read from an invalid address
(found on a Power8 guest).

Instead, use the DMA address of the dummy page because it will always
be safe.

Fixes: d8f60cfc9345 ("drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips (v3)")
Fixes: 25a857fbe973 ("drm/radeon/kms: add support for interrupts on SI")
Fixes: a59781bbe528 ("drm/radeon: add support for interrupts on CIK (v5)")
Signed-off-by: Sam Bobroff &lt;sbobroff@linux.ibm.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>dmaengine: ti: edma: fix missed failure handling</title>
<updated>2020-01-27T13:46:52+00:00</updated>
<author>
<name>Chuhong Yuan</name>
<email>hslester96@gmail.com</email>
</author>
<published>2019-11-18T07:38:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e3ba33cc5a94f5469865263bbb99c8ad3631ea3f'/>
<id>urn:sha1:e3ba33cc5a94f5469865263bbb99c8ad3631ea3f</id>
<content type='text'>
[ Upstream commit 340049d453682a9fe8d91fe794dd091730f4bb25 ]

When devm_kcalloc fails, it forgets to call edma_free_slot.
Replace direct return with failure handler to fix it.

Fixes: 1be5336bc7ba ("dmaengine: edma: New device tree binding")
Signed-off-by: Chuhong Yuan &lt;hslester96@gmail.com&gt;
Link: https://lore.kernel.org/r/20191118073802.28424-1-hslester96@gmail.com
Signed-off-by: Vinod Koul &lt;vkoul@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>affs: fix a memory leak in affs_remount</title>
<updated>2020-01-27T13:46:52+00:00</updated>
<author>
<name>Navid Emamdoost</name>
<email>navid.emamdoost@gmail.com</email>
</author>
<published>2019-10-02T21:52:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=beb22d9386c3eab7938f6920e01768e98a3924e9'/>
<id>urn:sha1:beb22d9386c3eab7938f6920e01768e98a3924e9</id>
<content type='text'>
[ Upstream commit 450c3d4166837c496ebce03650c08800991f2150 ]

In affs_remount if data is provided it is duplicated into new_opts.  The
allocated memory for new_opts is only released if parse_options fails.

There's a bit of history behind new_options, originally there was
save/replace options on the VFS layer so the 'data' passed must not
change (thus strdup), this got cleaned up in later patches. But not
completely.

There's no reason to do the strdup in cases where the filesystem does
not need to reuse the 'data' again, because strsep would modify it
directly.

Fixes: c8f33d0bec99 ("affs: kstrdup() memory handling")
Signed-off-by: Navid Emamdoost &lt;navid.emamdoost@gmail.com&gt;
[ update changelog ]
Signed-off-by: David Sterba &lt;dsterba@suse.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>mmc: core: fix wl1251 sdio quirks</title>
<updated>2020-01-27T13:46:52+00:00</updated>
<author>
<name>H. Nikolaus Schaller</name>
<email>hns@goldelico.com</email>
</author>
<published>2019-11-07T10:30:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8c17dd4b587bed444f1ea58bfc9bd90f44bf9db3'/>
<id>urn:sha1:8c17dd4b587bed444f1ea58bfc9bd90f44bf9db3</id>
<content type='text'>
[ Upstream commit 16568b4a4f0c34bd35cfadac63303c7af7812764 ]

wl1251 and wl1271 have different vendor id and device id.
So we need to handle both with sdio quirks.

Fixes: 884f38607897 ("mmc: core: move some sdio IDs out of quirks file")
Signed-off-by: H. Nikolaus Schaller &lt;hns@goldelico.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.11+
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>mmc: sdio: fix wl1251 vendor id</title>
<updated>2020-01-27T13:46:52+00:00</updated>
<author>
<name>H. Nikolaus Schaller</name>
<email>hns@goldelico.com</email>
</author>
<published>2019-11-07T10:30:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7effc7cf857317e78fdaa9111243ee9d24a8e80f'/>
<id>urn:sha1:7effc7cf857317e78fdaa9111243ee9d24a8e80f</id>
<content type='text'>
[ Upstream commit e5db673e7fe2f971ec82039a28dc0811c2100e87 ]

v4.11-rc1 did introduce a patch series that rearranged the
sdio quirks into a header file. Unfortunately this did forget
to handle SDIO_VENDOR_ID_TI differently between wl1251 and
wl1271 with the result that although the wl1251 was found on
the sdio bus, the firmware did not load any more and there was
no interface registration.

This patch defines separate constants to be used by sdio quirks
and drivers.

Fixes: 884f38607897 ("mmc: core: move some sdio IDs out of quirks file")
Signed-off-by: H. Nikolaus Schaller &lt;hns@goldelico.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.11+
Signed-off-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
