<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/include, branch v4.17.13</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.17.13</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.17.13'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2018-08-03T05:48:06Z</updated>
<entry>
<title>tcp: add max_quickacks param to tcp_incr_quickack and tcp_enter_quickack_mode</title>
<updated>2018-08-03T05:48:06Z</updated>
<author>
<name>Eric Dumazet</name>
<email>edumazet@google.com</email>
</author>
<published>2018-05-21T22:08:56Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=8893617eeb196a6a13ff87bbbd143e11fa4965a8'/>
<id>urn:sha1:8893617eeb196a6a13ff87bbbd143e11fa4965a8</id>
<content type='text'>
[ Upstream commit 9a9c9b51e54618861420093ae6e9b50a961914c5 ]

We want to add finer control of the number of ACK packets sent after
ECN events.

This patch is not changing current behavior, it only enables following
change.

Signed-off-by: Eric Dumazet &lt;edumazet@google.com&gt;
Acked-by: Soheil Hassas Yeganeh &lt;soheil@google.com&gt;
Acked-by: Neal Cardwell &lt;ncardwell@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm: Add DP PSR2 sink enable bit</title>
<updated>2018-08-03T05:48:02Z</updated>
<author>
<name>José Roberto de Souza</name>
<email>jose.souza@intel.com</email>
</author>
<published>2018-03-28T22:30:37Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ac70c738be06434ab7d28cf5877e7395f22139ab'/>
<id>urn:sha1:ac70c738be06434ab7d28cf5877e7395f22139ab</id>
<content type='text'>
[ Upstream commit 4f212e40468650e220c1770876c7f25b8e0c1ff5 ]

To comply with eDP1.4a this bit should be set when enabling PSR2.

Signed-off-by: José Roberto de Souza &lt;jose.souza@intel.com&gt;
Reviewed-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Signed-off-by: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180328223046.16125-1-jose.souza@intel.com
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>ASoC: topology: Add missing clock gating parameter when parsing hw_configs</title>
<updated>2018-08-03T05:48:02Z</updated>
<author>
<name>Kirill Marinushkin</name>
<email>k.marinushkin@gmail.com</email>
</author>
<published>2018-04-04T04:19:38Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=636ef9d6b1acbb6e9d640b9febb6b3840735c47e'/>
<id>urn:sha1:636ef9d6b1acbb6e9d640b9febb6b3840735c47e</id>
<content type='text'>
[ Upstream commit 933e1c4a667103c4d10ebdc9505a0a6abd8c3fbd ]

Clock gating parameter is a part of `dai_fmt`. It is supported by
`alsa-lib` when creating a topology binary file, but ignored by kernel
when loading this topology file.

After applying this commit, the clock gating parameter is not ignored any
more. This solution is backwards compatible. The existing behaviour is
not broken, because by default the parameter value is 0 and is ignored.

snd_soc_tplg_hw_config.clock_gated = 0 =&gt; no effect
snd_soc_tplg_hw_config.clock_gated = 1 =&gt; SND_SOC_DAIFMT_GATED
snd_soc_tplg_hw_config.clock_gated = 2 =&gt; SND_SOC_DAIFMT_CONT

For example, the following config, based on
alsa-lib/src/conf/topology/broadwell/broadwell.conf, is now supported:

~~~~
SectionHWConfig."CodecHWConfig" {
        id "1"
        format "I2S"            # physical audio format.
        pm_gate_clocks "true"   # clock can be gated
}

SectionLink."Codec" {

        # used for binding to the physical link
        id "0"

        hw_configs [
                "CodecHWConfig"
        ]

        default_hw_conf_id "1"
}
~~~~

Signed-off-by: Kirill Marinushkin &lt;k.marinushkin@gmail.com&gt;
Reviewed-by: Pierre-Louis Bossart &lt;pierre-louis.bossart@linux.intel.com&gt;
Cc: Jaroslav Kysela &lt;perex@perex.cz&gt;
Cc: Takashi Iwai &lt;tiwai@suse.de&gt;
Cc: Mark Brown &lt;broonie@kernel.org&gt;
Cc: Pan Xiuli &lt;xiuli.pan@linux.intel.com&gt;
Cc: Liam Girdwood &lt;liam.r.girdwood@linux.intel.com&gt;
Cc: linux-kernel@vger.kernel.org
Cc: alsa-devel@alsa-project.org
Signed-off-by: Mark Brown &lt;broonie@kernel.org&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>ASoC: topology: Fix bclk and fsync inversion in set_link_hw_format()</title>
<updated>2018-08-03T05:48:02Z</updated>
<author>
<name>Kirill Marinushkin</name>
<email>k.marinushkin@gmail.com</email>
</author>
<published>2018-04-04T04:19:37Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=671dc72c2c3773eb3b81bdf9d49514be598c313f'/>
<id>urn:sha1:671dc72c2c3773eb3b81bdf9d49514be598c313f</id>
<content type='text'>
[ Upstream commit a941e2fab3207cb0d57dc4ec47b1b12c8ea78b84 ]

The values of bclk and fsync are inverted WRT the codec. But the existing
solution already works for Broadwell, see the alsa-lib config:

`alsa-lib/src/conf/topology/broadwell/broadwell.conf`

This commit provides the backwards-compatible solution to fix this misuse.

Signed-off-by: Kirill Marinushkin &lt;k.marinushkin@gmail.com&gt;
Reviewed-by: Pierre-Louis Bossart &lt;pierre-louis.bossart@linux.intel.com&gt;
Tested-by: Pan Xiuli &lt;xiuli.pan@linux.intel.com&gt;
Tested-by: Pierre-Louis Bossart &lt;pierre-louis.bossart@linux.intel.com&gt;
Cc: Jaroslav Kysela &lt;perex@perex.cz&gt;
Cc: Takashi Iwai &lt;tiwai@suse.de&gt;
Cc: Mark Brown &lt;broonie@kernel.org&gt;
Cc: Liam Girdwood &lt;liam.r.girdwood@linux.intel.com&gt;
Cc: linux-kernel@vger.kernel.org
Cc: alsa-devel@alsa-project.org
Signed-off-by: Mark Brown &lt;broonie@kernel.org&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>regulator: Don't return or expect -errno from of_map_mode()</title>
<updated>2018-08-03T05:48:00Z</updated>
<author>
<name>Douglas Anderson</name>
<email>dianders@chromium.org</email>
</author>
<published>2018-04-18T15:54:18Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=99cf307b59c8c9007e7c02a8cd2b2269a8e5ad6e'/>
<id>urn:sha1:99cf307b59c8c9007e7c02a8cd2b2269a8e5ad6e</id>
<content type='text'>
[ Upstream commit 02f3703934a42417021405ef336fe45add13c3d1 ]

In of_get_regulation_constraints() we were taking the result of
of_map_mode() (an unsigned int) and assigning it to an int.  We were
then checking whether this value was -EINVAL.  Some implementers of
of_map_mode() were returning -EINVAL (even though the return type of
their function needed to be unsigned int) because they needed to
signal an error back to of_get_regulation_constraints().

In general in the regulator framework the mode is always referred to
as an unsigned int.  While we could fix this to be a signed int (the
highest value we store in there right now is 0x8), it's actually
pretty clean to just define the regulator mode 0x0 (the lack of any
bits set) as an invalid mode.  Let's do that.

Fixes: 5e5e3a42c653 ("regulator: of: Add support for parsing initial and suspend modes")
Suggested-by: Javier Martinez Canillas &lt;javierm@redhat.com&gt;
Signed-off-by: Douglas Anderson &lt;dianders@chromium.org&gt;
Reviewed-by: Javier Martinez Canillas &lt;javierm@redhat.com&gt;
Signed-off-by: Mark Brown &lt;broonie@kernel.org&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>serial: core: Make sure compiler barfs for 16-byte earlycon names</title>
<updated>2018-08-03T05:48:00Z</updated>
<author>
<name>Douglas Anderson</name>
<email>dianders@chromium.org</email>
</author>
<published>2018-03-23T17:58:31Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=64b8131944f14ef2b977b5a72c062507a6c87bc0'/>
<id>urn:sha1:64b8131944f14ef2b977b5a72c062507a6c87bc0</id>
<content type='text'>
[ Upstream commit c1c734cb1f54b062f7e67ffc9656d82f5b412b9c ]

As part of bringup I ended up wanting to call an earlycon driver by a
name that was exactly 16-bytes big, specifically "qcom_geni_serial".

Unfortunately, when I tried this I found that things compiled just
fine.  They just didn't work.

Specifically the compiler felt perfectly justified in initting the
".name" field of "struct earlycon_id" with the full 16-bytes and just
skipping the '\0'.  Needless to say, that behavior didn't seem ideal,
but I guess someone must have allowed it for a reason.

One way to fix this is to shorten the name field to 15 bytes and then
add an extra byte after that nobody touches.  This should always be
initted to 0 and we're golden.

There are, of course, other ways to fix this too.  We could audit all
the users of the "name" field and make them stop at both null
termination or at 16 bytes.  We could also just make the name field
much bigger so that we're not likely to run into this.  ...but both
seem like we'll just hit the bug again.

Signed-off-by: Douglas Anderson &lt;dianders@chromium.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&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>memory: tegra: Apply interrupts mask per SoC</title>
<updated>2018-08-03T05:47:58Z</updated>
<author>
<name>Dmitry Osipenko</name>
<email>digetx@gmail.com</email>
</author>
<published>2018-04-09T19:28:29Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=bce56f0cb64a1e0a461e1aba39c666958d5aaa40'/>
<id>urn:sha1:bce56f0cb64a1e0a461e1aba39c666958d5aaa40</id>
<content type='text'>
[ Upstream commit 1c74d5c0de0c2cc29fef97a19251da2ad6f579bd ]

Currently we are enabling handling of interrupts specific to Tegra124+
which happen to overlap with previous generations. Let's specify
interrupts mask per SoC generation for consistency and in a preparation
of squashing of Tegra20 driver into the common one that will enable
handling of GART faults which may be undesirable by newer generations.

Signed-off-by: Dmitry Osipenko &lt;digetx@gmail.com&gt;
Signed-off-by: Thierry Reding &lt;treding@nvidia.com&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>delayacct: Use raw_spinlocks</title>
<updated>2018-08-03T05:47:57Z</updated>
<author>
<name>Sebastian Andrzej Siewior</name>
<email>bigeasy@linutronix.de</email>
</author>
<published>2018-04-23T16:10:23Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=fe52ec8c67bf1b2b026e857b7b49c6c2f3b6363a'/>
<id>urn:sha1:fe52ec8c67bf1b2b026e857b7b49c6c2f3b6363a</id>
<content type='text'>
[ Upstream commit 02acc80d19edb0d5684c997b2004ad19f9f5236e ]

try_to_wake_up() might invoke delayacct_blkio_end() while holding the
pi_lock (which is a raw_spinlock_t). delayacct_blkio_end() acquires
task_delay_info.lock which is a spinlock_t. This causes a might sleep splat
on -RT where non raw spinlocks are converted to 'sleeping' spinlocks.

task_delay_info.lock is only held for a short amount of time so it's not a
problem latency wise to make convert it to a raw spinlock.

Signed-off-by: Sebastian Andrzej Siewior &lt;bigeasy@linutronix.de&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Balbir Singh &lt;bsingharora@gmail.com&gt;
Link: https://lkml.kernel.org/r/20180423161024.6710-1-bigeasy@linutronix.de
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>mm, powerpc, x86: define VM_PKEY_BITx bits if CONFIG_ARCH_HAS_PKEYS is enabled</title>
<updated>2018-08-03T05:47:54Z</updated>
<author>
<name>Ram Pai</name>
<email>linuxram@us.ibm.com</email>
</author>
<published>2018-03-27T09:09:26Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=0225a1b338770d5d419242466dd0f4248c1c67c1'/>
<id>urn:sha1:0225a1b338770d5d419242466dd0f4248c1c67c1</id>
<content type='text'>
[ Upstream commit 5212213aa5a2359dd0474c9dab22b6220b591fe1 ]

VM_PKEY_BITx are defined only if CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
is enabled. Powerpc also needs these bits. Hence lets define the
VM_PKEY_BITx bits for any architecture that enables
CONFIG_ARCH_HAS_PKEYS.

Reviewed-by: Dave Hansen &lt;dave.hansen@intel.com&gt;
Signed-off-by: Ram Pai &lt;linuxram@us.ibm.com&gt;
Reviewed-by: Ingo Molnar &lt;mingo@kernel.org&gt;
Reviewed-by: Aneesh Kumar K.V &lt;aneesh.kumar@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>brcmfmac: Add support for bcm43364 wireless chipset</title>
<updated>2018-08-03T05:47:53Z</updated>
<author>
<name>Sean Lanigan</name>
<email>sean@lano.id.au</email>
</author>
<published>2018-05-04T06:48:23Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=7f07963e9cc5fd36225a19db83b55e4a04c2e984'/>
<id>urn:sha1:7f07963e9cc5fd36225a19db83b55e4a04c2e984</id>
<content type='text'>
[ Upstream commit 9c4a121e82634aa000a702c98cd6f05b27d6e186 ]

Add support for the BCM43364 chipset via an SDIO interface, as used in
e.g. the Murata 1FX module.

The BCM43364 uses the same firmware as the BCM43430 (which is already
included), the only difference is the omission of Bluetooth.

However, the SDIO_ID for the BCM43364 is 02D0:A9A4, giving it a MODALIAS
of sdio:c00v02D0dA9A4, which doesn't get recognised and hence doesn't
load the brcmfmac module. Adding the 'A9A4' ID in the appropriate place
triggers the brcmfmac driver to load, and then correctly use the
firmware file 'brcmfmac43430-sdio.bin'.

Signed-off-by: Sean Lanigan &lt;sean@lano.id.au&gt;
Acked-by: Ulf Hansson &lt;ulf.hansson@linaro.org&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&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>
</feed>
