On Tue, Jun 20, 2017 at 02:10:08AM -0700, Guenter Roeck wrote:
> Confirmed. All builds and qemu tests passed with v3.10.106-267-g4242a2a.
Nice, thank you Guenter!
Willy
Hi Kees,
Thanks for reviewing.
I will update in V1 soon.
Br,
Orson
On 20 June 2017 at 03:01, Kees Cook wrote:
> On Fri, Jun 16, 2017 at 2:28 AM, Orson Zhai wrote:
>> Sysctl test will fail in some items if the value of /proc/sys/kernel
>> /sysctrl_writes_strict is 0 as the default value in ker
On Mon, Jun 19, 2017 at 06:55:47PM -0700, Stephen Boyd wrote:
> On 05/15, Dong Aisheng wrote:
> > diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> > index a6efbb9..4466cae 100644
> > --- a/include/linux/clk-provider.h
> > +++ b/include/linux/clk-provider.h
> > @@ -557,6 +5
On Tue, Jun 20, 2017 at 08:59:00AM +0200, Ard Biesheuvel wrote:
> As it turns out, arm64 deviates from other architectures in the way it
> maps the VMALLOC region: on most (all?) other architectures, it resides
> strictly above the kernel's direct mapping of DRAM, but on arm64, this
> is the other
From: Borislav Petkov
When hpet=force is supplied on the kernel command line and the HPET
supports the Legacy Replacement Interrupt Route option (HPET_ID_LEGSUP),
the legacy interrupts init code uses the boot CPU's mask initially by
calling smp_processor_id() assuming that it is running on the BS
Here, rx/tx allocation can fail. So avoid kvfree call
with NULL pointer.
Signed-off-by: Arvind Yadav
---
drivers/spi/spi-loopback-test.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/spi/spi-loopback-test.c b/drivers/spi/spi-loopback-test.c
index f4875f
On Tue, Jun 13, 2017 at 8:16 AM, wrote:
> From: Fenglin Wu
>
> Power source selection in DIG_VIN_CTL is indexed from 0, in the range
> check it shouldn't be equal to the total number of power sources.
>
> Signed-off-by: Fenglin Wu
> ---
> drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 2 +-
> 1 f
On 19/06/17 23:44, Julien Gomes wrote:
> Add Netlink notifications on cache reports in ipmr, in addition to the
> existing igmpmsg sent to mroute_sk.
> Send RTM_NEWCACHEREPORT notifications to RTNLGRP_IPV4_MROUTE_R.
>
> MSGTYPE, VIF_ID, SRC_ADDR and DST_ADDR Netlink attributes contain the
> same d
On Mon, Jun 19, 2017 at 07:00:13PM -0700, Stephen Boyd wrote:
> On 05/15, Dong Aisheng wrote:
> > diff --git a/drivers/clk/imx/clk.h b/drivers/clk/imx/clk.h
> > index 51b84e4..665777e 100644
> > --- a/drivers/clk/imx/clk.h
> > +++ b/drivers/clk/imx/clk.h
> > @@ -69,6 +69,12 @@ struct clk *imx_clk_b
On Mon, Jun 19, 2017 at 06:59:17PM -0700, Stephen Boyd wrote:
> On 05/15, Dong Aisheng wrote:
> > obj-$(CONFIG_SOC_IMX1) += clk-imx1.o
> > diff --git a/drivers/clk/imx/clk-pllv4.c b/drivers/clk/imx/clk-pllv4.c
> > new file mode 100644
> > index 000..502da64
> > --- /dev/null
> > +++ b/driver
On Tue, Jun 13, 2017 at 5:15 AM, Baolin Wang wrote:
> I forgot one most important reason why we can not use the "sleep" state. As I
> explained
> above, the sleep related configuration will bind with the pin's sleep mode.
> If we set the
> pin's sleep mode as AP_SLEEP, then we can select "sleep
On Mon, Jun 19, 2017 at 04:11:35PM -0400, Andrey Grodzovsky wrote:
>
>
> On 06/19/2017 03:24 PM, Sean Paul wrote:
> > On Mon, Jun 19, 2017 at 11:35:28AM -0400, Harry Wentland wrote:
> > > On 2017-06-09 05:30 PM, Andrey Grodzovsky wrote:
> > > > Problem:
> > > > While running IGT kms_atomic_transi
On Wed, Jun 14, 2017 at 6:49 AM, Masahiro Yamada
wrote:
> The pingroups dump of debugfs hits WARN_ON() in pinctrl_groups_show().
> Filling non-existing ports with '-1' turned out a bad idea.
>
> Fixes: 70f2f9c4cf25 ("pinctrl: uniphier: add UniPhier PH1-LD11 pinctrl
> driver")
> Signed-off-by: Ma
On Wed, Jun 14, 2017 at 6:49 AM, Masahiro Yamada
wrote:
> The pingroups dump of debugfs hits WARN_ON() in pinctrl_groups_show().
> Filling non-existing ports with '-1' turned out a bad idea.
>
> Fixes: 336306ee1f2d ("pinctrl: uniphier: add UniPhier PH1-LD20 pinctrl
> driver")
> Signed-off-by: Ma
On Tue, Jun 20, 2017 at 11:22:05AM +0200, Thomas Gleixner wrote:
> If the interrupt _IS_ screaming because the hardware is buggered, then the
> nobody cared thing will detect it and switch it off. That's all what we can
> do, aside of not loading the driver at all.
>
> But that's way better than s
On Wed, Jun 14, 2017 at 5:11 PM, Andreas Dilger wrote:
> Another option that might be less complex is to just add the xattr inodes
> to the orphan list in the main transaction (which should be a fixed number
> of credits), and then truncate/unlink the xattr inodes after the main
> transaction has
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc-li...@googlegroups.com
On Mon, Jun 19, 2017 at 05:45:21PM +0200, Noralf Trønnes wrote:
>
> Den 19.06.2017 15.17, skrev Liviu Dudau:
> > On Fri, Jun 16, 2017 at 06:58:36PM +0200, Noralf Trønnes wrote:
> > > Den 16.06.2017 15.53, skrev Liviu Dudau:
> > > > Update the PM code to suspend/resume the fbdev_cma console.
> > >
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
For the same reasons use set_mmss64 callback instead of set_mmss
Signed-off-by: Benjamin Gaignard
CC: Alessa
Migrated pubek_show to struct tpm_buf and cleaned up its implementation.
Previously the output parameter structure was declared but left
completely unused. Now it is used to refer different fields of the
output. We can move it to tpm-sysfs.c as it does not have any use
outside of that file.
Signed
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: "Rafael J. Wysocki"
CC: Pavel Machek
CC: Len Brown
CC: Alessandro Zum
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc-li...@googlegroups.com
On Sat, Jun 17, 2017 at 07:48:04PM +0200, Peter Rosin wrote:
> The clut is not synchronized with the drm gamma_lut state.
>
> Signed-off-by: Peter Rosin
This needs to be done in the fbdev helper, not like this. Yes it's an old
issue, but forcing every driver to duplicate code like this isn't coo
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
For the same reasons use set_mmss64 callback instead of set_mmss
Since only set_mmss64 be will used remove mod
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
For the same reasons use set_mmss64 callback instead of set_mmss
Signed-off-by: Benjamin Gaignard
CC: Alessa
On Sat, Jun 17, 2017 at 07:48:02PM +0200, Peter Rosin wrote:
> All layers of all supported chips support this, the only variable is the
> base address of the lookup table in the register map.
>
> Signed-off-by: Peter Rosin
As Boris said, pls use the new color manager stuff for atomic drivers, an
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc-li...@googlegroups.com
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
For the same reasons use set_mmss64 callback instead of set_mmss
Signed-off-by: Benjamin Gaignard
CC: Alessa
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc-li...@googlegroups.com
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Thierry Reding
CC: Jonathan Hunter
CC: Alessandro Zummo
CC: Alexandre
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc-li...@googlegroups.com
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc-li...@googlegroups.com
This patch set cleans up clutter and cruft from EK sysfs code and fixes
a kernel memory leak.
Jarkko Sakkinen (2):
tpm: fix a kernel memory leak in tpm-sysfs.c
tpm: migrate pubek_show to struct tpm_buf
drivers/char/tpm/tpm-sysfs.c | 86
drivers/ch
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Maxime Ripard
CC: Chen-Yu Tsai
CC: Alessandro Zummo
CC: Alexandre Bel
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc-li...@googlegroups.com
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
For the same reasons use set_mmss64 callback instead of set_mmss
Signed-off-by: Benjamin Gaignard
CC: Alessa
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
For the same reasons use set_mmss64 callback instead of set_mmss
Signed-off-by: Benjamin Gaignard
CC: Vladim
While cleaning up sysfs callback that prints EK we discovered a kernel
memory leak. This commit fixes the issue by zeroing the buffer used for
TPM command/response.
The leak happen when we use either tpm_vtpm_proxy, tpm_ibmvtpm or
xen-tpmfront.
Cc: sta...@vger.kernel.org
Fixes: 0883743825e3 ("TPM
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: Barry Song
CC: rtc-li...@g
On Mon, Jun 19, 2017 at 07:01:19PM -0700, Stephen Boyd wrote:
> On 05/15, Dong Aisheng wrote:
> > +
> > + clks[IMX7ULP_CLK_VIU] = imx_clk_gate("viu", "nic1_clk",
> > base + 0xA0, 30);
> > + clks[IMX7ULP_CLK_PCTLC] = imx_clk_gate("pctlc", "nic1_bus_clk",
> > base + 0xB8
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc-li...@googlegroups.com
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc-li...@googlegroups.com
Hi Luca,
thanks for joining!
On Wed, Jun 14, 2017 at 6:12 PM, Luca Porzio (lporzio)
wrote:
> This behavior is not Micron specific but instead it is enforced by the Jedec
> Specification. All eMMC must have HW reset disabled by default.
That's very good to know.
> This specification (as Ulf co
Hi,
On Friday 16 June 2017 09:24 PM, Cyrille Pitchen wrote:
> Hi all,
>
> + Richard and Boris as MTD maintainers
>
> Le 25/04/2017 à 14:18, Vignesh R a écrit :
>>
>>
>> On Friday 21 April 2017 10:36 PM, Mark Brown wrote:
>>> On Tue, Apr 11, 2017 at 05:22:25PM +0530, Vignesh R wrote:
Flash f
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Linus Walleij
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc-li..
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc-li...@googlegroups.com
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc-li...@googlegroups.com
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc-li...@googlegroups.com
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
For the same reasons use set_mmss64 callback instead of set_mmss
Signed-off-by: Benjamin Gaignard
CC: Alessa
Hi Matthias,
2017-06-20 3:37 GMT+09:00 Matthias Kaehlcke :
> cc-option uses KBUILD_CFLAGS and KBUILD_CPPFLAGS when it determines
> whether an option is supported or not. This is fine for options used to
> build the kernel itself, however some components like the x86 boot code
> use a different set
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
For the same reasons use set_mmss64 callback instead of set_mmss
Signed-off-by: Benjamin Gaignard
CC: Alessa
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
For the same reasons use set_mmss64 callback instead of set_mmss
Signed-off-by: Benjamin Gaignard
CC: Alessa
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc-li...@googlegroups.com
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc-li...@googlegroups.com
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Hans Ulli Kroll
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc-li
On Tue, Jun 20, 2017 at 5:36 AM, Theodore Ts'o wrote:
> On Tue, Jun 20, 2017 at 10:53:35AM +0200, Jason A. Donenfeld wrote:
>> > Suppressing all messages for all configurations cast a wider net than
>> > necessary. Configurations that could potentially be detected and fixed
>> > likely will go unn
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
For the same reasons use set_mmss64 callback instead of set_mmss
Signed-off-by: Benjamin Gaignard
CC: Alessa
On Tue, Jun 20, 2017 at 11:36 AM, Theodore Ts'o wrote:
>> But I think there's another camp that would mutiny in the face of this
>> kind of hubris.
>
> Blocking the boot for hours and hours until we have enough entropy to
> initialize the CRNG is ***not*** an acceptable way of making the
> warning
Hi,
On Sun, Jun 18, 2017 at 09:00:17PM +0800, Ziping Chen wrote:
> From: Ziping Chen
>
> The Allwinner A83T's MMC can work with
> compatible "allwinner,sun7i-a20-mmc".
>
> Add support for it.
This has been proven not to be the case already.
Please use an A83T compatible only.
Maxime
--
Max
Thanks Andreas for the feedback. Please see my responses below:
> It would be preferable to allow a mount option like "no_mbcache" to disable
> the use of shared xattrs. In the Lustre case at least, there will never be
> shared large xattrs, and we've had a bunch of performance issues with mbcach
On Tue, Jun 20, 2017 at 10:07:06AM +0200, Quentin Schulz wrote:
> Hi Adrian,
>
> On 20/06/2017 09:39, Adrian Hunter wrote:
> > On 16/06/17 10:29, Quentin Schulz wrote:
> >> This adds deepest (Backup+Self-Refresh) PM support to the ATMEL SAMA5D2
> >> SoC's SDHCI controller.
> >>
> >> When resuming
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc-li...@googlegroups.com
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc-li...@googlegroups.com
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc-li...@googlegroups.com
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc-li...@googlegroups.com
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Baruch Siach
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc-li...
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
For the same reasons use set_mmss64 callback instead of set_mmss
Signed-off-by: Benjamin Gaignard
CC: Alessa
On 19/06/17 23:44, Julien Gomes wrote:
> Add Netlink notifications on cache reports in ip6mr, in addition to the
> existing mrt6msg sent to mroute6_sk.
> Send RTM_NEWCACHEREPORT notifications to RTNLGRP_IPV6_MROUTE_R.
>
> MSGTYPE, MIF_ID, SRC_ADDR and DST_ADDR Netlink attributes contain the
> same
On Mon, Jun 19, 2017 at 5:36 AM, Jan Kara wrote:
> Heh, this "pushing of responsibility" looks like a silly game. If an error
> can happen in a function, it is better to report it as far as easily
> possible (unless we can cleanly handle it which we cannot here). I'm guilty
> of making dquot_free_
On 19 June 2017 at 17:31, Krzysztof Kozlowski wrote:
> Although header is included only once but still having an include guard
> is a good practice. To avoid confusion, add SoC prefix to existing
> Exynos5433 header include guard.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> include/video/exy
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Linus Walleij
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc-li..
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Support Opensource
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc-li...@googlegroups.com
On 2017-06-20 11:40, Daniel Vetter wrote:
> On Sat, Jun 17, 2017 at 07:48:02PM +0200, Peter Rosin wrote:
>> All layers of all supported chips support this, the only variable is the
>> base address of the lookup table in the register map.
>>
>> Signed-off-by: Peter Rosin
>
> As Boris said, pls use
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc-li...@googlegroups.com
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc-li...@googlegroups.com
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Support Opensource
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc-li...@googlegroups.com
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc-li...@googlegroups.com
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Jason Cooper
CC: Gregory Clement
CC: Sebastian Hesselbarth
CC: Alessa
On Tue, 2017-06-20 at 15:10 +1000, Balbir Singh wrote:
> On Fri, 2017-06-16 at 20:52 -0700, Ram Pai wrote:
> > Memory protection keys enable applications to protect its
> > address space from inadvertent access or corruption from
> > itself.
>
> I presume by itself you mean protection between thre
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Linus Walleij
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc-li..
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc-li...@googlegroups.com
On Tue, Jun 20, 2017 at 11:52:08AM +0900, Minchan Kim wrote:
> Hello Kirill,
>
> On Mon, Jun 19, 2017 at 05:03:23PM +0300, Kirill A. Shutemov wrote:
> > On Fri, Jun 16, 2017 at 11:53:33PM +0900, Minchan Kim wrote:
> > > Hi Andrea,
> > >
> > > On Fri, Jun 16, 2017 at 04:27:20PM +0200, Andrea Arcan
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Alessandro Zummo
CC: Alexandre Belloni
CC: rtc-li...@googlegroups.com
On Tue, Jun 20, 2017 at 10:53:35AM +0200, Jason A. Donenfeld wrote:
> > Suppressing all messages for all configurations cast a wider net than
> > necessary. Configurations that could potentially be detected and fixed
> > likely will go unnoticed. If the problem is not brought to light, then
> > it
On 2017-06-20 09:58, Willy Tarreau wrote:
On Tue, Jun 20, 2017 at 09:31:00AM +0200, Rafal Milecki wrote:
Do you know if my name will appear correctly in git [0]?
[0]
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/?h=linux-3.10.y
I would have almost promised it wa
Add SPDIFRX support to STM32.
Signed-off-by: olivier moysan
---
sound/soc/stm/Kconfig | 10 +
sound/soc/stm/Makefile| 4 +
sound/soc/stm/stm32_spdifrx.c | 998 ++
3 files changed, 1012 insertions(+)
create mode 100644 sound/soc/stm/stm3
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Thomas Gleixner
CC: Ingo Molnar
CC: x...@kernel.org
CC: John Stultz
C
Hi,
On Tue, Jun 20, 2017 at 10:58:19AM +0200, Corentin Labbe wrote:
> The Security System have a PRNG, this patch add support for it via
> crypto_rng.
This might be a dumb question, but is the CRYPTO_RNG code really
supposed to be used with PRNG?
> Signed-off-by: Corentin Labbe
> ---
> drivers
Hi Uffe,
On 2017/6/20 9:36, Ulf Hansson wrote:
> Hi Wei,
>
> On 19 June 2017 at 15:00, Wei Xu wrote:
>> Hi Ulf,
>>
>> On 2017/6/19 13:43, Ulf Hansson wrote:
>>> On 14 June 2017 at 10:23, Guodong Xu wrote:
Add bindings for hi3660 mmc support
Signed-off-by: Li Wei
Signed-off-
Add documentation of device tree bindings for the
STM32 SPDIFRX interface.
Signed-off-by: olivier moysan
---
.../devicetree/bindings/sound/st,stm32-spdifrx.txt | 56 ++
1 file changed, 56 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/st,stm32-spdif
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Michael Chan
CC: net...@vger.kernel.org
CC: linux-kernel@vger.kernel.or
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
The goal of this series of patches is ti stop using those two functions
and use instead to safer 64bits ones.
It also remove change .set_mmss to set_mmss64 callba
This patch-set handles the SPDIFRX on STM32 platforms.
The SPDIFRX peripheral, is designed to receive an S/PDIF flow compliant with
IEC-60958 and IEC-61937 standards.
SPDIFRX uses two DMA channels:
- one DMA channel for S/PDIF data stream.
- one DMA channel for control flow (channel status and us
rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
rely on 32bits variables and that will make rtc break in y2038/2016.
Stop using those two functions to safer 64bits ones.
Signed-off-by: Benjamin Gaignard
CC: Thomas Gleixner
CC: Ingo Molnar
CC: x...@kernel.org
CC: linux-kernel@v
On Tue, Jun 20, 2017 at 11:53 AM, Emil Velikov wrote:
> On 19 June 2017 at 17:31, Krzysztof Kozlowski wrote:
>> Although header is included only once but still having an include guard
>> is a good practice. To avoid confusion, add SoC prefix to existing
>> Exynos5433 header include guard.
>>
>>
On 20/06/2017 at 11:35:08 +0200, Benjamin Gaignard wrote:
> rtc_time_to_tm() and rtc_tm_to_time() are deprecated because they
> rely on 32bits variables and that will make rtc break in y2038/2016.
Please don't, because this hide the fact that the hardware will not
handle dates in y2038 anyway and
In order to support OPP switching, OPP layer needs to get pointer to the
clock for the device. Simple cases work fine without using the routines
added by this patch (i.e. by passing connection-id as NULL), but for a
device with multiple clocks available, the OPP core needs to know the
exact name o
synths[] array caches currently loaded synths. synth_add checks
synths[] before adding a new one. It however ignores the result of
do_synth_init. So when do_synth_init fails, the failed synth is still
cached. Since, as a result module loading fails too, synth_remove -
which is responsible for remov
201 - 300 of 1130 matches
Mail list logo
