Re: [PATCH 4.14 000/164] 4.14.6-stable review
On Wed, Dec 13, 2017 at 09:49:32AM +0100, Daniel Vetter wrote: > On Wed, Dec 13, 2017 at 8:57 AM, Greg Kroah-Hartman > wrote: > > On Wed, Dec 13, 2017 at 07:48:43AM +0100, Marek Szyprowski wrote: > >> Hi Shuah and Greg, > >> > >> On 2017-12-12 15:47, Shuah Khan wrote: > >> > On 12/12/2017 05:43 AM, Greg Kroah-Hartman wrote: > >> > > This is the start of the stable review cycle for the 4.14.6 release. > >> > > There are 164 patches in this series, all will be posted as a response > >> > > to this one. If anyone has any issues with these being applied, please > >> > > let me know. > >> > > > >> > > Responses should be made by Thu Dec 14 12:34:08 UTC 2017. > >> > > Anything received after that time might be too late. > >> > > > >> > > The whole patch series can be found in one patch at: > >> > > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.6-rc1.gz > >> > > or in the git tree and branch at: > >> > > > >> > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > >> > > linux-4.14.y > >> > > and the diffstat can be found below. > >> > > > >> > > thanks, > >> > > > >> > > greg k-h > >> > > > >> > > Daniel Vetter > >> > > drm: safely free connectors from connector_iter > >> > > > >> > > Marek Szyprowski > >> > > drm/bridge: analogix dp: Fix runtime PM state in get_modes() > >> > > callback > >> > > > >> > The above two patches have been found to be the cause of boot hang on > >> > exynos Peach Pi(t) chromebooks. > >> > > >> > I am adding Daniel and Marek to the thread. > >> > >> The deadlock is caused by the Daniels patch. My patch only changes the > >> order > >> of device initialization what might hide or reveal bug related to Daniels > >> patch. > > > > So should I revert Daniel's patch? Or is there already a fix for that > > in Linus's tree? > > Not yet, still typing it. Hopefully all in time for -rc4. I think > reverting it for now should be ok, I'll annotate the cc: stable lines > for the new ones with a note that you need to re-cherry-pick it to > make it all work. Thanks, I've dropped this for now. greg k-h
Re: [PATCH 4.14 000/164] 4.14.6-stable review
On Tue, Dec 12, 2017 at 02:54:58PM -0700, Shuah Khan wrote: > On 12/12/2017 05:43 AM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.14.6 release. > > There are 164 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Thu Dec 14 12:34:08 UTC 2017. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.6-rc1.gz > > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-4.14.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Compiled and booted on my test system. No dmesg regressions. Thanks for the testing and letting me know. greg k-h
Re: [PATCH 4.14 000/164] 4.14.6-stable review
On Wed, Dec 13, 2017 at 10:45:39PM +0530, Naresh Kamboju wrote: > On 12 December 2017 at 18:13, Greg Kroah-Hartman > wrote: > > This is the start of the stable review cycle for the 4.14.6 release. > > There are 164 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Thu Dec 14 12:34:08 UTC 2017. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.6-rc1.gz > > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-4.14.y > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > Results from Linaro’s test farm. > No regressions on arm64 and x86_64. > armv7 beagleboard x15 results are not available due to infrastructure issues. > > Note: > Newly added selftests/net/reuseport_bpf FAILED in full run on x86_64 and > the independent test execution resulted as PASS. That's odd, it's not good when test infrastructure doesn't work :( Anyway, thanks for testing and letting me know. greg k-h
Re: [PATCH] driver core: Make it safe to use get_device() if the reference count is zero
On Thu, Dec 14, 2017 at 03:56:46PM +0800, Jason Yan wrote:
>
> On 2017/12/14 15:42, Greg KH wrote:
> > On Thu, Dec 14, 2017 at 11:39:36AM +0800, Jason Yan wrote:
> > > Some driviers may have the chance to increase a reference count that
> > > has dropped to zero when using get_device() because of their design.
> > Then those drivers are broken :)
> >
> > > We have met such a issue with scsi:
> > > https://www.spinics.net/lists/linux-scsi/msg115295.html
> > >
> > > The scsi core will keep the scsi device object in the host list after
> > > it has been deleted and the iterator can still find it. All of the
> > > places where need iterating have to check the state of the scsi device
> > > and this makes a lot of code redundancy and complexity.
> > >
> > > Provide a safe mechanism in get_device() by using
> > > kobject_get_unless_zero().
> > >
> > > Suggested-by: Bart Van Assche
> > > Signed-off-by: Jason Yan
> > > CC: Greg Kroah-Hartman
> > > CC: Bart Van Assche
> > > CC: Ewan D. Milne
> > > CC: James E.J. Bottomley
> > > CC: Christoph Hellwig
> > > ---
> > > drivers/base/core.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/base/core.c b/drivers/base/core.c
> > > index 12ebd05..cc74810 100644
> > > --- a/drivers/base/core.c
> > > +++ b/drivers/base/core.c
> > > @@ -1916,7 +1916,7 @@ EXPORT_SYMBOL_GPL(device_register);
> > >*/
> > > struct device *get_device(struct device *dev)
> > > {
> > > - return dev ? kobj_to_dev(kobject_get(&dev->kobj)) : NULL;
> > > + return dev && kobject_get_unless_zero(&dev->kobj) ? dev : NULL;
> > I really don't want to do this, the bus the device is on should prevent
> > this from happening.
> >
> > Also, once that reference count drops to zero, the memory should be
> > freed, so you really have a stale pointer here, and this code would fail
> > if you had slab debugging enabled anyway.
>
> Actually I don't want this either. But the design of scsi core will leave
> the scsi device on the host list after it is deleted, and it can be
> found later and the refcount have a very big chance to increase from
> zero again. And after a lot of discussion it seems that the scsi layer
> is difficult to change the situation in the near future.
Keeping a 'struct device' reference counted chunk of memory on a list
that has a different lifetime rule from that device itself, is crazy.
And yes, I remember how all of this came about, but I really don't have
the time to work on it myself...
> > So I don't even think this fixes the issue you think it fixes :)
>
> This issue is very easy to reproduce on my machine and I have tested the
> patch and it really fixes the issue.
Even with slab debugging enabled? If so, what is keeping that memory
from being freed once the reference count drops to 0?
I think you are just papering over the real issue here, which is one
reason I really do not like the get_unless_zero() function at all.
thanks,
greg k-h
Re: [PATCH] ASoC: sun4i-i2s: Show detailed error when DAI configuration callbacks fail
On Thu, Dec 14, 2017 at 03:29:28PM +0800, Chen-Yu Tsai wrote: > When any of the DAI hardware configuration callbacks (.hw_param, > .set_fmt, .set_sysclk) fails, there is no explanation about why it > failed. This is particularly confusing for .hw_param, which covers > many parameters of the DAI. Telling the users what parameter isn't > supported, and what the requested value was goes a long way for > developers trying to combine sun4i-i2s with external codecs. > > This patch adds dev_err calls explaining what isn't supported or > failed, and what the value was. sun4i_i2s_set_clk_rate()'s first > parameter was changed to a struct snd_soc_dai *dai, so we can > get the underlying device. > > Signed-off-by: Chen-Yu Tsai Acked-by: Maxime Ripard Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH v2] drm: rcar-du: calculate DPLLCR to be more small jitter
Hi Morimoto-san,
On Thursday, 14 December 2017 04:10:27 EET Kuninori Morimoto wrote:
> Hi Laurent
>
> Thank you for your feedback
>
> >> + * NOTES
> >> + * N = (n + 1), M = (m + 1), P = 2
> >> + * 2000 < fvco < 4096Mhz
> >
> > Are you sure that the fvco constraint is really 2kHz, and not 2GHz ? 2kHz
> > - 4GHz would be a surprisingly large range.
>
> It is 2kHz. This is came from HW team, and indicated
> on HW design sheet (?)
OK, it's a surprising VCO, no issue with that :-)
> >> + * Basically M=1
> >
> > Why is this ?
>
> This is came from HW team, too.
> They are assuming M=1, basically.
> But yes confusable, let's remove it from comment.
> m is started from 0 (= M=1), no need to explain.
Sounds good to me.
> >> + for (m = 0; m < 4; m++) {
> >> + for (n = 119; n > 38; n--) {
> >> + unsigned long long fvco = input * 2 * (n + 1) / (m + 1);
> >
> > This code runs for Gen3 only, so unsigned long would be enough. The rest
> > of the function already relies on native support for 64-bit calculation.
> > If you wanted to run this on a 32-bit CPU, you would likely need to
> > do_div() for the division, and convert input to u64 to avoid integer
> > overflows, otherwise the calculation will be performed on 32-bit before a
> > final conversion to 64-bit.
>
> (snip)
>
> >> + if ((fvco < 2000) ||
> >> + (fvco > 409600ll))
> >
> > No need for the inner parentheses, and you can write both conditions on a
> > single line. Furthemore 4096 MHz will fit in a 32-bit number, so there's
> > no need for the ll.
>
> Yes, but compiled by 32bit too, right ?
> Without this "ll", 32bit compiler say
>
> warning: this decimal constant is unsigned only in ISO C90
That's right. How about 409600UL then, to force unsigned integer types ?
Or possibly even better, 4096 * 1000 * 1000UL to make it more readable ?
> # anyway, I will add this assumption (= used only by 64bit CPU)
> # on comment to avoid future confusion
>
> > I think you can then drop the output >= 40 check inside the inner
> > fdpll loop, as the output frequency can't be higher than 4GHz if the VCO
> > frequency isn't.
>
> I think code has
>
> if (output >= 4)
>
> This is 400MHz, not 4GHz
You're right, my bad. Maybe I should write it 400 * 1000 * 1000 :-)
> >>for (fdpll = 1; fdpll < 32; fdpll++) {
> >>unsigned long output;
> >
> > The output frequency on the line below can be calculated with
> >
> > output = fvco / 2 / (fdpll + 1)
> >
> > to avoid the multiplication by (n + 1) and division by (m + 1).
>
> It is nice idea to avoid extra calculation.
> I will use this idea, and add extrate comment to avoid confusion
Thank you.
--
Regards,
Laurent Pinchart
Re: [alsa-devel] [PATCH v10 08/13] regmap: add SLIMbus support
On Thu, 14 Dec 2017 06:17:39 +0100, Vinod Koul wrote: > > On Wed, Dec 13, 2017 at 04:06:11PM +, Mark Brown wrote: > > > On Mon, Dec 11, 2017 at 11:43:02PM +, srinivas.kandaga...@linaro.org > > > wrote: > > > > > Mark, can I get an Ack for this patch so I can take it through my tree > > > with the other patches in this series? > > > > I'm actually not seeing a direct dependency here (there's a depends in > > place stopping the regmap code building if the Slimbus core isn't > > enabled) so if you want you can go ahead and apply the main stuff and I > > can apply the regmap change separately, it'll avoid Makefile/Kconfig > > conflicts anyway. > > + Takashi > > FWIW, since this is another MIPI Audio specfic bus, would it make sense for > this series to go thru sound/ tree? I have discussed with Takashi and Greg > for soundwire and we are taking sound path. > > Would that be okay here too? Either ways I dont mind :) Me too, I don't mind who takes what. Just let me know. thanks, Takashi
Re: [PATCH] ASoC: sun4i-i2s: Show detailed error when DAI configuration callbacks fail
On 14 December 2017 at 08:29, Chen-Yu Tsai wrote:
> When any of the DAI hardware configuration callbacks (.hw_param,
> .set_fmt, .set_sysclk) fails, there is no explanation about why it
> failed. This is particularly confusing for .hw_param, which covers
> many parameters of the DAI. Telling the users what parameter isn't
> supported, and what the requested value was goes a long way for
> developers trying to combine sun4i-i2s with external codecs.
>
> This patch adds dev_err calls explaining what isn't supported or
> failed, and what the value was. sun4i_i2s_set_clk_rate()'s first
> parameter was changed to a struct snd_soc_dai *dai, so we can
> get the underlying device.
>
> Signed-off-by: Chen-Yu Tsai
Acked-by: Marcus Cooper
Thanks...I can get rid of shit loads of my debugging now.
> ---
> sound/soc/sunxi/sun4i-i2s.c | 36 ++--
> 1 file changed, 30 insertions(+), 6 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
> index 13d7ecabe1b6..dca1143c1150 100644
> --- a/sound/soc/sunxi/sun4i-i2s.c
> +++ b/sound/soc/sunxi/sun4i-i2s.c
> @@ -269,10 +269,11 @@ static bool sun4i_i2s_oversample_is_valid(unsigned int
> oversample)
> return false;
> }
>
> -static int sun4i_i2s_set_clk_rate(struct sun4i_i2s *i2s,
> +static int sun4i_i2s_set_clk_rate(struct snd_soc_dai *dai,
> unsigned int rate,
> unsigned int word_size)
> {
> + struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai);
> unsigned int oversample_rate, clk_rate;
> int bclk_div, mclk_div;
> int ret;
> @@ -300,6 +301,7 @@ static int sun4i_i2s_set_clk_rate(struct sun4i_i2s *i2s,
> break;
>
> default:
> + dev_err(dai->dev, "Unsupported sample rate: %u\n", rate);
> return -EINVAL;
> }
>
> @@ -308,18 +310,25 @@ static int sun4i_i2s_set_clk_rate(struct sun4i_i2s *i2s,
> return ret;
>
> oversample_rate = i2s->mclk_freq / rate;
> - if (!sun4i_i2s_oversample_is_valid(oversample_rate))
> + if (!sun4i_i2s_oversample_is_valid(oversample_rate)) {
> + dev_err(dai->dev, "Unsupported oversample rate: %d\n",
> + oversample_rate);
> return -EINVAL;
> + }
>
> bclk_div = sun4i_i2s_get_bclk_div(i2s, oversample_rate,
> word_size);
> - if (bclk_div < 0)
> + if (bclk_div < 0) {
> + dev_err(dai->dev, "Unsupported BCLK divider: %d\n", bclk_div);
> return -EINVAL;
> + }
>
> mclk_div = sun4i_i2s_get_mclk_div(i2s, oversample_rate,
> clk_rate, rate);
> - if (mclk_div < 0)
> + if (mclk_div < 0) {
> + dev_err(dai->dev, "Unsupported MCLK divider: %d\n", mclk_div);
> return -EINVAL;
> + }
>
> /* Adjust the clock division values if needed */
> bclk_div += i2s->variant->bclk_offset;
> @@ -349,8 +358,11 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream
> *substream,
> u32 width;
>
> channels = params_channels(params);
> - if (channels != 2)
> + if (channels != 2) {
> + dev_err(dai->dev, "Unsupported number of channels: %d\n",
> + channels);
> return -EINVAL;
> + }
>
> if (i2s->variant->has_chcfg) {
> regmap_update_bits(i2s->regmap, SUN8I_I2S_CHAN_CFG_REG,
> @@ -382,6 +394,8 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream
> *substream,
> width = DMA_SLAVE_BUSWIDTH_2_BYTES;
> break;
> default:
> + dev_err(dai->dev, "Unsupported physical sample width: %d\n",
> + params_physical_width(params));
> return -EINVAL;
> }
> i2s->playback_dma_data.addr_width = width;
> @@ -393,6 +407,8 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream
> *substream,
> break;
>
> default:
> + dev_err(dai->dev, "Unsupported sample width: %d\n",
> + params_width(params));
> return -EINVAL;
> }
>
> @@ -401,7 +417,7 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream
> *substream,
> regmap_field_write(i2s->field_fmt_sr,
>sr + i2s->variant->fmt_offset);
>
> - return sun4i_i2s_set_clk_rate(i2s, params_rate(params),
> + return sun4i_i2s_set_clk_rate(dai, params_rate(params),
> params_width(params));
> }
>
> @@ -426,6 +442,8 @@ static int sun4i_i2s_set_fmt(struct snd_soc_dai *dai,
> unsigned int fmt)
> val = SUN4I_I2S_FMT0_FMT_RIGHT_J;
> break;
> default:
> + dev_err(dai->dev, "Unsupported format: %d\n",
> +
Re: [PATCH] driver core: Make it safe to use get_device() if the reference count is zero
On 2017/12/14 16:10, Greg KH wrote:
On Thu, Dec 14, 2017 at 03:56:46PM +0800, Jason Yan wrote:
On 2017/12/14 15:42, Greg KH wrote:
On Thu, Dec 14, 2017 at 11:39:36AM +0800, Jason Yan wrote:
Some driviers may have the chance to increase a reference count that
has dropped to zero when using get_device() because of their design.
Then those drivers are broken :)
We have met such a issue with scsi:
https://www.spinics.net/lists/linux-scsi/msg115295.html
The scsi core will keep the scsi device object in the host list after
it has been deleted and the iterator can still find it. All of the
places where need iterating have to check the state of the scsi device
and this makes a lot of code redundancy and complexity.
Provide a safe mechanism in get_device() by using
kobject_get_unless_zero().
Suggested-by: Bart Van Assche
Signed-off-by: Jason Yan
CC: Greg Kroah-Hartman
CC: Bart Van Assche
CC: Ewan D. Milne
CC: James E.J. Bottomley
CC: Christoph Hellwig
---
drivers/base/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 12ebd05..cc74810 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1916,7 +1916,7 @@ EXPORT_SYMBOL_GPL(device_register);
*/
struct device *get_device(struct device *dev)
{
- return dev ? kobj_to_dev(kobject_get(&dev->kobj)) : NULL;
+ return dev && kobject_get_unless_zero(&dev->kobj) ? dev : NULL;
I really don't want to do this, the bus the device is on should prevent
this from happening.
Also, once that reference count drops to zero, the memory should be
freed, so you really have a stale pointer here, and this code would fail
if you had slab debugging enabled anyway.
Actually I don't want this either. But the design of scsi core will leave
the scsi device on the host list after it is deleted, and it can be
found later and the refcount have a very big chance to increase from
zero again. And after a lot of discussion it seems that the scsi layer
is difficult to change the situation in the near future.
Keeping a 'struct device' reference counted chunk of memory on a list
that has a different lifetime rule from that device itself, is crazy.
The lifetime rule is the same. That device itself will delete from the
host list in the destructor, scsi_device_dev_release_usercontext(), and
the memory will be freed after that. That's why this issue came out.
And yes, I remember how all of this came about, but I really don't have
the time to work on it myself...
So I don't even think this fixes the issue you think it fixes :)
This issue is very easy to reproduce on my machine and I have tested the
patch and it really fixes the issue.
Even with slab debugging enabled? If so, what is keeping that memory
from being freed once the reference count drops to 0?
As above, the memory is not freed yet when we increasing the refconunt
from zero, so it's nothing to do with slab debugging enabled or not. If
we want to free it, we have to grab host lock first to delete it from
the list, so if we are grabing the host lock, we can increase the
refcount safely from 0 to 1.
I think you are just papering over the real issue here, which is one
reason I really do not like the get_unless_zero() function at all.
thanks,
greg k-h
.
Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")
On Wed, Dec 13, 2017 at 16:54:17 -0800, Laura Abbott wrote: Hi, Fedora got a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1520982 of a boot failure/bug on Linus' master (full bootlog at the bugzilla) I'm available for testing. The problem happens on my x86_64 Dell Workstation, but not an old i386 server or an x86_64 mac hardware based laptop.
Re: [PATCH 0/8] drm/sun4i: Support the Display Engine frontend
Hi Thomas, On Wed, Dec 13, 2017 at 05:16:22PM +0100, Thomas van Kleef wrote: > Hi, > > On 13-12-17 16:33, Maxime Ripard wrote: > > Hi, > > > > This is a first serie to enable the display engine frontend. > > > > This hardware block is found in the first generation Display Engine from > > Allwinner. Its role is to implement more advanced features that the > > associated backend, even though the backend alone can be used (and was used > > so far) for basic composition. > > > > Among those features, we will find hardware scaling, that is supported in > > this serie, colorspace conversions, or more exotic formats support such as > > the one output by the VPU. > > So, if I have read the code correctly. The frontend will be used whenever the > input size differs from the output size. Yes :) My current plan is to extend it as needed when we'll need to deal with a format not supported by the backend (for the VPU), or anything the backend cannot support. Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH v4 00/15] drm/sun4i: Add A83t LVDS support
On Thu, Dec 14, 2017 at 07:01:57AM +, Priit Laes wrote: > On Thu, Dec 07, 2017 at 04:58:45PM +0100, Maxime Ripard wrote: > > Hi, > > > > Here is an attempt at supporting the LVDS output in our DRM driver. This > > has been tested on the A83T (with DE2), but since everything is basically > > in the TCON, it should also be usable on the older SoCs with minor > > modifications. > > I managed to get the single-channel LVDS working on an A10 tablet after > doing those minor modifications (although, the colours are off a bit). > So in general this series looks good :) Is that a Tested-by? :) Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH 39/45] arch/s390: remove duplicate includes
On Sun, Dec 10, 2017 at 11:56:57PM +0530, Pravin Shedge wrote: > These duplicate includes have been found with scripts/checkincludes.pl but > they have been removed manually to avoid removing false positives. > > Signed-off-by: Pravin Shedge > --- > arch/s390/kernel/kprobes.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/s390/kernel/kprobes.c b/arch/s390/kernel/kprobes.c > index af3722c..943d13e 100644 > --- a/arch/s390/kernel/kprobes.c > +++ b/arch/s390/kernel/kprobes.c > @@ -20,7 +20,6 @@ > #include > #include > #include > -#include > #include Applied, thanks.
Re: [PATCH v2] drm: rcar-du: calculate DPLLCR to be more small jitter
Hi Laurent,
On Thu, Dec 14, 2017 at 9:17 AM, Laurent Pinchart
wrote:
> On Thursday, 14 December 2017 04:10:27 EET Kuninori Morimoto wrote:
>> >> + if ((fvco < 2000) ||
>> >> + (fvco > 409600ll))
>> >
>> > No need for the inner parentheses, and you can write both conditions on a
>> > single line. Furthemore 4096 MHz will fit in a 32-bit number, so there's
>> > no need for the ll.
>>
>> Yes, but compiled by 32bit too, right ?
>> Without this "ll", 32bit compiler say
>>
>> warning: this decimal constant is unsigned only in ISO C90
>
> That's right. How about 409600UL then, to force unsigned integer types ?
> Or possibly even better, 4096 * 1000 * 1000UL to make it more readable ?
If it's just about making the number unsigned, and not about 64-bit arithmetic,
a "U" suffix should be sufficient.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH] driver core: Make it safe to use get_device() if the reference count is zero
On Thu, Dec 14, 2017 at 04:27:56PM +0800, Jason Yan wrote:
>
>
> On 2017/12/14 16:10, Greg KH wrote:
> > On Thu, Dec 14, 2017 at 03:56:46PM +0800, Jason Yan wrote:
> > >
> > > On 2017/12/14 15:42, Greg KH wrote:
> > > > On Thu, Dec 14, 2017 at 11:39:36AM +0800, Jason Yan wrote:
> > > > > Some driviers may have the chance to increase a reference count that
> > > > > has dropped to zero when using get_device() because of their design.
> > > > Then those drivers are broken :)
> > > >
> > > > > We have met such a issue with scsi:
> > > > > https://www.spinics.net/lists/linux-scsi/msg115295.html
> > > > >
> > > > > The scsi core will keep the scsi device object in the host list after
> > > > > it has been deleted and the iterator can still find it. All of the
> > > > > places where need iterating have to check the state of the scsi device
> > > > > and this makes a lot of code redundancy and complexity.
> > > > >
> > > > > Provide a safe mechanism in get_device() by using
> > > > > kobject_get_unless_zero().
> > > > >
> > > > > Suggested-by: Bart Van Assche
> > > > > Signed-off-by: Jason Yan
> > > > > CC: Greg Kroah-Hartman
> > > > > CC: Bart Van Assche
> > > > > CC: Ewan D. Milne
> > > > > CC: James E.J. Bottomley
> > > > > CC: Christoph Hellwig
> > > > > ---
> > > > >drivers/base/core.c | 2 +-
> > > > >1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/drivers/base/core.c b/drivers/base/core.c
> > > > > index 12ebd05..cc74810 100644
> > > > > --- a/drivers/base/core.c
> > > > > +++ b/drivers/base/core.c
> > > > > @@ -1916,7 +1916,7 @@ EXPORT_SYMBOL_GPL(device_register);
> > > > > */
> > > > >struct device *get_device(struct device *dev)
> > > > >{
> > > > > - return dev ? kobj_to_dev(kobject_get(&dev->kobj)) : NULL;
> > > > > + return dev && kobject_get_unless_zero(&dev->kobj) ? dev : NULL;
> > > > I really don't want to do this, the bus the device is on should prevent
> > > > this from happening.
> > > >
> > > > Also, once that reference count drops to zero, the memory should be
> > > > freed, so you really have a stale pointer here, and this code would fail
> > > > if you had slab debugging enabled anyway.
> > >
> > > Actually I don't want this either. But the design of scsi core will leave
> > > the scsi device on the host list after it is deleted, and it can be
> > > found later and the refcount have a very big chance to increase from
> > > zero again. And after a lot of discussion it seems that the scsi layer
> > > is difficult to change the situation in the near future.
> >
> > Keeping a 'struct device' reference counted chunk of memory on a list
> > that has a different lifetime rule from that device itself, is crazy.
> >
>
> The lifetime rule is the same. That device itself will delete from the
> host list in the destructor, scsi_device_dev_release_usercontext(), and
> the memory will be freed after that. That's why this issue came out.
>
> > And yes, I remember how all of this came about, but I really don't have
> > the time to work on it myself...
> >
> > > > So I don't even think this fixes the issue you think it fixes :)
> > >
> > > This issue is very easy to reproduce on my machine and I have tested the
> > > patch and it really fixes the issue.
> >
> > Even with slab debugging enabled? If so, what is keeping that memory
> > from being freed once the reference count drops to 0?
> >
>
> As above, the memory is not freed yet when we increasing the refconunt from
> zero, so it's nothing to do with slab debugging enabled or not. If
> we want to free it, we have to grab host lock first to delete it from
> the list, so if we are grabing the host lock, we can increase the
> refcount safely from 0 to 1.
Wait, what? Once that refcount goes to 0, the release callback will be
called, and the memory had better be freed. Any pointer you might still
have to the structure is now invalid. The fact that you are somehow
still keeping that pointer around is not ok, and slab debugging should
have caused the memory to be overwritten and garbage would result if you
tried to make this call again.
thanks,
greg k-h
Re: [PATCH v3] spi: s3c64xx: add SPDX identifier
On Thu, Dec 14, 2017 at 7:28 AM, Andi Shyti wrote: > Replace the original license statement with the SPDX identifier. > > Signed-off-by: Andi Shyti > Reviewed-by: Krzysztof Kozlowski > --- > Hi, > > v2 to v3: > - move the SPDX identifier on top as a separate comment as per >documentation > - add Krzysztof's review > > v1 to v2: > - keep the original license > > Andi > > drivers/spi/spi-s3c64xx.c | 18 -- > include/linux/platform_data/spi-s3c64xx.h | 6 ++ > 2 files changed, 6 insertions(+), 18 deletions(-) > > diff --git a/drivers/spi/spi-s3c64xx.c b/drivers/spi/spi-s3c64xx.c > index de7df20f8712..baa3a9fa2638 100644 > --- a/drivers/spi/spi-s3c64xx.c > +++ b/drivers/spi/spi-s3c64xx.c > @@ -1,17 +1,7 @@ > -/* > - * Copyright (C) 2009 Samsung Electronics Ltd. > - * Jaswinder Singh > - * > - * This program is free software; you can redistribute it and/or modify > - * it under the terms of the GNU General Public License as published by > - * the Free Software Foundation; either version 2 of the License, or > - * (at your option) any later version. > - * > - * This program is distributed in the hope that it will be useful, > - * but WITHOUT ANY WARRANTY; without even the implied warranty of > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > - * GNU General Public License for more details. > - */ > +// SPDX-License-Identifier: GPL-2.0+ > +// > +// Copyright (c) 2009 Samsung Electronics Co., Ltd. > +// Jaswinder Singh > > #include > #include > diff --git a/include/linux/platform_data/spi-s3c64xx.h > b/include/linux/platform_data/spi-s3c64xx.h > index da79774078a7..773daf7915a3 100644 > --- a/include/linux/platform_data/spi-s3c64xx.h > +++ b/include/linux/platform_data/spi-s3c64xx.h > @@ -1,10 +1,8 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > + > /* > * Copyright (C) 2009 Samsung Electronics Ltd. > * Jaswinder Singh > - * > - * This program is free software; you can redistribute it and/or modify > - * it under the terms of the GNU General Public License version 2 as > - * published by the Free Software Foundation. > */ > > #ifndef __SPI_S3C64XX_H > -- > 2.15.1 > Acked-by: Philippe Ombredanne Thanks! -- Cordially Philippe Ombredanne
Re: [PATCH 1/2] mm: NUMA stats code cleanup and enhancement
On 2017年12月14日 15:29, Michal Hocko wrote: > On Thu 14-12-17 09:40:32, kemi wrote: >> >> >> or sometimes >> NUMA stats can't be disabled in their environments. > > why? > >> That's the reason >> why we spent time to do that optimization other than simply adding a runtime >> configuration interface. >> >> Furthermore, the code we optimized for is the core area of kernel that can >> benefit most of kernel actions, more or less I think. >> >> All right, let's think about it in another way, does a u64 percpu array >> per-node >> for NUMA stats really make code too much complicated and hard to maintain? >> I'm afraid not IMHO. > > I disagree. The whole numa stat things has turned out to be nasty to > maintain. For a very limited gain. Now you are just shifting that > elsewhere. Look, there are other counters taken in the allocator, we do > not want to treat them specially. We have a nice per-cpu infrastructure > here so I really fail to see why we should code-around it. If that can > be improved then by all means let's do it. > Yes, I agree with you that we may improve current per-cpu infrastructure. May we have a chance to increase the size of vm_node_stat_diff from s8 to s16 for this "per-cpu infrastructure" (s32 in per-cpu counter infrastructure)? The limitation of type s8 seems not enough with more and more cpu cores, especially for those monotone increasing type of counters like NUMA counters. before after(moving numa to per_cpu_nodestat and change s8 to s16) sizeof(struct per_cpu_nodestat) 28 68 If ok, we can also keep that improvement in a nice way.
Re: [PATCH v6 00/14] soundwire: Add a new SoundWire subsystem
Vinod, On Thu, Dec 14, 2017 at 6:49 AM, Vinod Koul wrote: > We are going to merge this series thru sound tree, need Mark's ack on > regmap patch or to take it thru regmap tree. > > This patch series adds a new SoundWire subsystem which implements a > new MIPI bus protocol 'SoundWire'. > > The SoundWire protocol is a robust, scalable, low complexity, low > power, low latency, two-pin (clock and data) multi-drop bus that > allows for the transfer of multiple audio streams and embedded > control/commands. SoundWire provides synchronization capabilities > and supports both PCM and PDM, multichannel data, isochronous and > asynchronous modes. > > This series adds SoundWire Bus, IO transfers, DisCo (Discovery and > Configuration) sysfs interface, regmap and Documentation summary. > > This patch series is also available on > git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/soundwire.git > topic/patch_v6 > > v5: https://lkml.org/lkml/2017/12/6/545 > v4: https://lkml.org/lkml/2017/12/1/205 > v3: https://lkml.org/lkml/2017/11/30/160 > v2: https://lkml.org/lkml/2017/11/10/216 > v1: https://lkml.org/lkml/2017/10/18/1030 > RFC: https://lkml.org/lkml/2016/10/21/395 > > Changes in v6: > - Add reviewed/acked tags from Philippe, Pierre, Takashi and Greg > - Fix nitpicks from Takashi > - Drop the sysfs patch for now > > Changes in v5: > - Address comments by Pierre > - add reference to mid.mipi.org in documentation > - add group and master device number and don't use those for enumeration > - fix unused calls in disco code and also remove superfluous initialization > - remove sdw_transfer apis slave arg, make enum values integer and not > bitmaps > - clarify the sdw_program_device_num loop and fix interrupt handling > > Changes in v4: > - Remove text licenses and add SPDX tags only with C99 style comments > - make bus_type code as GPL v2.0 only > > Changes in v3: > - Update the kernel-doc styles and fix included headers for files > - handle dev_pm_domain_attach() for defered probe > - remove OF placeholders > - change regmap license to GPLv2 only > > Changes in v2: > - move documentation into driver-api and do rst conversion > - fix documentation comments > - add SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) to all > source files > - rework the transfer logic and paging logic as commented on v1 > - remove dummy sysfs fns > - registration checks and fixes > - remove slave check for regamp as that turned superfluous > - remove depends SoundWire symbol > - make modalias api arg const > - use bitmap for tracking assigned > - add counter for report present tracking > todo: add the dt-bindings > > Sanyog Kale (4): > Documentation: Add SoundWire summary > soundwire: Add SoundWire MIPI defined registers > soundwire: Add Slave status handling helpers > soundwire: cdns: Add sdw_master_ops and IO transfer support > > Vinod Koul (10): > soundwire: Add SoundWire bus type > soundwire: Add Master registration > soundwire: Add MIPI DisCo property helpers > soundwire: Add IO transfer > regmap: Add SoundWire bus support > soundwire: Add slave status handling > soundwire: cdns: Add cadence library > soundwire: intel: Add Intel Master driver > soundwire: intel: Add Intel init module > MAINTAINERS: Add SoundWire entry > > Documentation/driver-api/index.rst | 1 + > Documentation/driver-api/soundwire/index.rst | 15 + > Documentation/driver-api/soundwire/summary.rst | 207 + > MAINTAINERS| 9 + > drivers/Kconfig| 2 + > drivers/Makefile | 1 + > drivers/base/regmap/Kconfig| 4 + > drivers/base/regmap/Makefile | 1 + > drivers/base/regmap/regmap-sdw.c | 92 +++ > drivers/soundwire/Kconfig | 37 + > drivers/soundwire/Makefile | 18 + > drivers/soundwire/bus.c| 997 > + > drivers/soundwire/bus.h| 71 ++ > drivers/soundwire/bus_type.c | 193 + > drivers/soundwire/cadence_master.c | 751 +++ > drivers/soundwire/cadence_master.h | 48 ++ > drivers/soundwire/intel.c | 345 + > drivers/soundwire/intel.h | 23 + > drivers/soundwire/intel_init.c | 198 + > drivers/soundwire/mipi_disco.c | 401 ++ > drivers/soundwire/slave.c | 114 +++ > include/linux/mod_devicetable.h| 6 + > include/linux/regmap.h | 37 + > include/linux/soundwire/sdw.h | 479 > include/linux/soundwire/sdw_intel.h| 24 + > include/linux/soundwire/sdw_registers.h| 194 + > include/linux/soundwire/sdw_type.h | 19 + > scripts/mod/devicetable-offset
Re: [PATCH] vmwgfx: use monotonic event timestamps
On Wed, Dec 13, 2017 at 9:56 PM, Sinclair Yeh wrote: > This looks okay to me. Although we should change eaction->tv_* type > to 64-bit as well. I thought about it but it would add significant complication without real gain, as the eaction->tv_* pointers point into uapi structures (drm_vmw_event_fence and drm_event_vblank) that are defined as 32-bit times and cannot be changed. Changing the temporary pointer to 64 bit would require adding a temporary variable to point to and then doing the truncation in the callers. With monotonic times, we know that 32-bit times are sufficient, they are good for 136 years after boot (68 years when interpreted as signed). Arnd
[PATCH] futex: Prevent overflow by strengthen input validation
UBSAN reports signed integer overflow in kernel/futex.c Test log as follows: UBSAN: Undefined behaviour in kernel/futex.c:2041:18 signed integer overflow: 0 - -2147483648 cannot be represented in type 'int' To prevent overflow, we don't allow nr_wake and nr_requeue to accept a negative entropy value. Signed-off-by: Li Jinyue --- kernel/futex.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/kernel/futex.c b/kernel/futex.c index 57d0b36..0abfa09 100644 --- a/kernel/futex.c +++ b/kernel/futex.c @@ -1878,6 +1878,9 @@ static int futex_requeue(u32 __user *uaddr1, unsigned int flags, struct futex_q *this, *next; DEFINE_WAKE_Q(wake_q); + if (nr_wake < 0 || nr_requeue < 0) + return -EINVAL; + /* * When PI not supported: return -ENOSYS if requeue_pi is true, * consequently the compiler knows requeue_pi is always false past -- 1.6.0.2
Re: [PATCH] mtd: mchp23k256: propagate return value of spi_sync()
On Sun, Dec 10, 2017 at 04:19:56PM +0100, Antonio Borneo wrote: > The call to spi_sync() can fail. > Check the return value and propagate it. > > Signed-off-by: Antonio Borneo Reviewed-by: Andrew Lunn Andrew
Re: [PATCH v8 2/2] mtd: nand: Add support for Arasan NAND Flash Controller
Dear Naga, On Thu, Dec 14, 2017 at 8:49 AM, Naga Sureshkumar Relli wrote: > Added the basic driver for Arasan NAND Flash Controller used in > Zynq UltraScale+ MPSoC. It supports only Hw ECC and upto 24bit > correction. > > Signed-off-by: Naga Sureshkumar Relli > Signed-off-by: Punnaiah Choudary Kalluri > --- /dev/null > +++ b/drivers/mtd/nand/arasan_nand.c > @@ -0,0 +1,1020 @@ > +/* > + * Arasan NAND Flash Controller Driver > + * > + * Copyright (C) 2014 - 2017 Xilinx, Inc. > + * > + * This program is free software; you can redistribute it and/or modify it > under > + * the terms of the GNU General Public License version 2 as published by the > + * Free Software Foundation; either version 2 of the License, or (at your > + * option) any later version. > + */ Could you use the new SPDX tags instead of this fine and long boilerplate? See Thomas doc for details [1] [1] https://lkml.org/lkml/2017/12/4/934 Thanks! -- Cordially Philippe Ombredanne
Re: [PATCH] platform/x86: dell-rbtn: Block comments use * on subsequent lines
> From: Joe Perches > Sent: Wednesday, December 13, 2017 9:09 PM > To: Dhaval Shah; Philippe Ombredanne > Cc: pali.ro...@gmail.com; Darren Hart; Andy Shevchenko; > platform-driver-...@vger.kernel.org; LKML > Subject: Re: [PATCH] platform/x86: dell-rbtn: Block comments use * on > subsequent lines > > On Wed, 2017-12-13 at 12:41 +, Dhaval Shah wrote: > > > If anyone does conversions of these license texts > > > you have to be _extremely_ careful about what > > > specific license identifier you use. > > > This license includes the text > > > "or (at your option) any later version" > > > which is not the same as using > > > SPDX-License-Identifier: GPL-2.0 > > > > I have given this SPDX ID based on the current license info in the driver. > > No, you have not. > You have done it incorrectly. > > For a short description, read: > https://spdx.org/sites/cpstandard/files/pages/files/using_spdx_license_list_short_identifiers.pdf > page 5 I got your point. SPDX text should be "SPDX-License-Identifier: GPL-2.0+". Am i Right?
Re: [patch 1/2] mm, mmu_notifier: annotate mmu notifiers with blockable invalidate callbacks
On Wed, 13 Dec 2017, Christian König wrote: > > > > --- a/drivers/misc/sgi-gru/grutlbpurge.c > > > > +++ b/drivers/misc/sgi-gru/grutlbpurge.c > > > > @@ -298,6 +298,7 @@ struct gru_mm_struct > > > > *gru_register_mmu_notifier(void) > > > > return ERR_PTR(-ENOMEM); > > > > STAT(gms_alloc); > > > > spin_lock_init(&gms->ms_asid_lock); > > > > + gms->ms_notifier.flags = 0; > > > > gms->ms_notifier.ops = &gru_mmuops; > > > > atomic_set(&gms->ms_refcnt, 1); > > > > init_waitqueue_head(&gms->ms_wait_queue); > > > > diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c > > > There is a kzalloc() just above this: > > > gms = kzalloc(sizeof(*gms), GFP_KERNEL); > > > > > > Is that not sufficient to clear the 'flags' field? > > > > > Absolutely, but whether it is better to explicitly document that the mmu > > notifier has cleared flags, i.e. there are no blockable callbacks, is > > another story. I can change it if preferred. > > Actually I would invert the new flag, in other words specify that an MMU > notifier will never sleep. > Very good idea, I'll do that. I'll also move the flags member to ops as Paolo suggested. Thanks both!
Re: mm/memcontrol.c:5364:1: warning: the frame size of 1032 bytes is larger than 1024 bytes [-Wframe-larger-than=]
On Thu 14-12-17 07:49:29, Paul Menzel wrote:
> Dear Linux folks,
>
>
> I enabled the undefined behavior sanitizer, and built Linus’ master branch
> under Ubuntu 17.10 with gcc (Ubuntu 7.2.0-8ubuntu3) 7.2.0.
>
> ```
> $ grep UBSAN /boot/config-4.15.0-rc3+
> CONFIG_ARCH_HAS_UBSAN_SANITIZE_ALL=y
> # CONFIG_ARCH_WANTS_UBSAN_NO_NULL is not set
> CONFIG_UBSAN=y
> CONFIG_UBSAN_SANITIZE_ALL=y
> # CONFIG_UBSAN_ALIGNMENT is not set
> CONFIG_UBSAN_NULL=y
> ```
>
> The warning below is shown when building Linux.
>
> ```
> $ git describe --tags
> v4.15-rc3-37-gd39a01eff9af
> $ git log --oneline -1
> d39a01eff9af (HEAD -> master, origin/master, origin/HEAD) Merge tag
> 'platform-drivers-x86-v4.15-3' of
> git://git.infradead.org/linux-platform-drivers-x86
> […]
> $ make -j
> […]
> mm/memcontrol.c: In function ‘memory_stat_show’:
> mm/memcontrol.c:5364:1: warning: the frame size of 1032 bytes is larger than
> 1024 bytes [-Wframe-larger-than=]
Interesting. My compiler does this
$ scripts/stackusage mm/memcontrol.o
$ grep memory_stat_show /tmp/stackusage.1405.RTP8
./mm/memcontrol.c:5526 memory_stat_show976 static
But this depends on the configuration because NR_VM_EVENT_ITEMS enables
some counters depending on the config. The stack is really large but
this is a function which is called from a shallow context wrt. stack so
we should fit into a single page. One way we could do, though, is to
make those large arrays static and use a internal lock around them.
Something like the following. What do you think Johannes?
---
>From d2ef50c2722f8465b169d4f7fad865478c2e9fed Mon Sep 17 00:00:00 2001
From: Michal Hocko
Date: Thu, 14 Dec 2017 10:12:22 +0100
Subject: [PATCH] mm, memcg: reduce memory_stat_show stack footprint
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
scripts/stackusage says that memory_stat_show consumes a lot of stack
space
./mm/memcontrol.c:5526 memory_stat_show976 static
The size can be even larger depending on the configuration. Paul Menzel
has even got the following warning for his distribution config:
mm/memcontrol.c: In function ‘memory_stat_show’:
mm/memcontrol.c:5364:1: warning: the frame size of 1032 bytes is larger than
1024 bytes [-Wframe-larger-than=]
The stack usage should be safe because this function is called from
shallow context but let's make those two large arrays static and
synchronize callers by a mutex. This might slow heavy parallel memcg
stat readers. If this ever turns out to be a problem we can drop those
arrays altogether and print the current snapshots of those counters
(this would be more prone to get inconsistent results though).
Reported-by: Paul Menzel
Signed-off-by: Michal Hocko
---
mm/memcontrol.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 8fa91d24a70b..784a4bd5fdf0 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -5526,8 +5526,9 @@ static int memory_events_show(struct seq_file *m, void *v)
static int memory_stat_show(struct seq_file *m, void *v)
{
struct mem_cgroup *memcg = mem_cgroup_from_css(seq_css(m));
- unsigned long stat[MEMCG_NR_STAT];
- unsigned long events[MEMCG_NR_EVENTS];
+ static unsigned long stat[MEMCG_NR_STAT];
+ static unsigned long events[MEMCG_NR_EVENTS];
+ static DEFINE_MUTEX(stat_lock);
int i;
/*
@@ -5540,7 +5541,7 @@ static int memory_stat_show(struct seq_file *m, void *v)
*
* Current memory state:
*/
-
+ mutex_lock(&stat_lock);
tree_stat(memcg, stat);
tree_events(memcg, events);
@@ -5601,6 +5602,7 @@ static int memory_stat_show(struct seq_file *m, void *v)
stat[WORKINGSET_ACTIVATE]);
seq_printf(m, "workingset_nodereclaim %lu\n",
stat[WORKINGSET_NODERECLAIM]);
+ mutex_unlock(&stat_lock);
return 0;
}
--
2.15.0
--
Michal Hocko
SUSE Labs
Re: [PATCH 1/2] mm: NUMA stats code cleanup and enhancement
On Thu 14-12-17 16:55:54, kemi wrote: > > > On 2017年12月14日 15:29, Michal Hocko wrote: > > On Thu 14-12-17 09:40:32, kemi wrote: > >> > >> > >> or sometimes > >> NUMA stats can't be disabled in their environments. > > > > why? > > > >> That's the reason > >> why we spent time to do that optimization other than simply adding a > >> runtime > >> configuration interface. > >> > >> Furthermore, the code we optimized for is the core area of kernel that can > >> benefit most of kernel actions, more or less I think. > >> > >> All right, let's think about it in another way, does a u64 percpu array > >> per-node > >> for NUMA stats really make code too much complicated and hard to maintain? > >> I'm afraid not IMHO. > > > > I disagree. The whole numa stat things has turned out to be nasty to > > maintain. For a very limited gain. Now you are just shifting that > > elsewhere. Look, there are other counters taken in the allocator, we do > > not want to treat them specially. We have a nice per-cpu infrastructure > > here so I really fail to see why we should code-around it. If that can > > be improved then by all means let's do it. > > > > Yes, I agree with you that we may improve current per-cpu infrastructure. > May we have a chance to increase the size of vm_node_stat_diff from s8 to s16 > for > this "per-cpu infrastructure" (s32 in per-cpu counter infrastructure)? The > limitation of type s8 seems not enough with more and more cpu cores, > especially > for those monotone increasing type of counters like NUMA counters. > >before after(moving numa to > per_cpu_nodestat > and change s8 to s16) > sizeof(struct per_cpu_nodestat) 28 68 > > If ok, we can also keep that improvement in a nice way. I wouldn't be opposed. Maybe we should make it nr_cpus sized. -- Michal Hocko SUSE Labs
[PATCH] scsi: ufs: add trace event for ufs upiu
Add UFS Protocol Information Units(upiu) trace events for ufs driver,
used to trace various ufs transaction types- command, task-management
and device management.
The trace-point format is generic and can be easily adapted to trace
other upius if needed.
Currently tracing ufs transaction of type 'device management', which
this patch introduce, cannot be obtained from any other trace.
Device management transactions are used for communication with the
device such as reading and writing descriptor or attributes etc.
Signed-off-by: Ohad Sharabi
---
drivers/scsi/ufs/ufshcd.c | 48 ++
include/trace/events/ufs.h | 28 +++
2 files changed, 76 insertions(+)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index a355d98..6d79c99 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -274,6 +274,47 @@ static inline void ufshcd_remove_non_printable(char *val)
*val = ' ';
}
+static void ufshcd_add_upiu_trace(struct ufs_hba *hba, unsigned int tag,
+ const char *str)
+{
+ struct utp_task_req_desc *descp;
+ struct utp_upiu_task_req *task_req;
+ struct utp_upiu_req *rq;
+ u8 tx_code, *hdr, *tsf;
+ int off;
+
+ if (!trace_ufshcd_upiu_enabled())
+ return;
+
+ off = (int)tag - hba->nutrs;
+ if (off < 0) {
+ rq = hba->lrb[tag].ucd_req_ptr;
+ hdr = (u8 *)&rq->header;
+ } else {
+ descp = &hba->utmrdl_base_addr[off];
+ task_req = (struct utp_upiu_task_req *)descp->task_req_upiu;
+ hdr = (u8 *)&task_req->header;
+ }
+
+ tx_code = hdr[0] & 0x3f;
+ switch (hdr[0] & 0x3f) {
+ case UPIU_TRANSACTION_COMMAND:
+ tsf = (u8 *)&rq->sc.cdb;
+ break;
+ case UPIU_TRANSACTION_TASK_REQ:
+ tsf = (u8 *)&task_req->input_param1;
+ break;
+ case UPIU_TRANSACTION_QUERY_REQ:
+ tsf = (u8 *)&rq->qr;
+ break;
+ default:
+ return;
+ }
+
+ /* trace UPIU header and Transaction Specific Fields (TSF) */
+ trace_ufshcd_upiu(dev_name(hba->dev), str, hdr, tsf);
+}
+
static void ufshcd_add_command_trace(struct ufs_hba *hba,
unsigned int tag, const char *str)
{
@@ -283,6 +324,9 @@ static void ufshcd_add_command_trace(struct ufs_hba *hba,
struct ufshcd_lrb *lrbp;
int transfer_len = -1;
+ /* trace UPIU also */
+ ufshcd_add_upiu_trace(hba, tag, str);
+
if (!trace_ufshcd_command_enabled())
return;
@@ -5462,11 +5506,14 @@ static int ufshcd_issue_tm_cmd(struct ufs_hba *hba, int
lun_id, int task_id,
spin_unlock_irqrestore(host->host_lock, flags);
+ ufshcd_add_upiu_trace(hba, task_tag, "tm_send");
+
/* wait until the task management command is completed */
err = wait_event_timeout(hba->tm_wq,
test_bit(free_slot, &hba->tm_condition),
msecs_to_jiffies(TM_CMD_TIMEOUT));
if (!err) {
+ ufshcd_add_upiu_trace(hba, task_tag, "tm_complete_err");
dev_err(hba->dev, "%s: task management cmd 0x%.2x timed-out\n",
__func__, tm_function);
if (ufshcd_clear_tm_cmd(hba, free_slot))
@@ -5475,6 +5522,7 @@ static int ufshcd_issue_tm_cmd(struct ufs_hba *hba, int
lun_id, int task_id,
err = -ETIMEDOUT;
} else {
err = ufshcd_task_req_compl(hba, free_slot, tm_response);
+ ufshcd_add_upiu_trace(hba, task_tag, "tm_complete");
}
clear_bit(free_slot, &hba->tm_condition);
diff --git a/include/trace/events/ufs.h b/include/trace/events/ufs.h
index bf6f826..0b2ff5d 100644
--- a/include/trace/events/ufs.h
+++ b/include/trace/events/ufs.h
@@ -257,6 +257,34 @@
)
);
+TRACE_EVENT(ufshcd_upiu,
+ TP_PROTO(const char *dev_name, const char *str, unsigned char *hdr,
+ unsigned char *tsf),
+
+ TP_ARGS(dev_name, str, hdr, tsf),
+
+ TP_STRUCT__entry(
+ __string(dev_name, dev_name)
+ __string(str, str)
+ __array(unsigned char, hdr, 12)
+ __array(unsigned char, tsf, 16)
+ ),
+
+ TP_fast_assign(
+ __assign_str(dev_name, dev_name);
+ __assign_str(str, str);
+ memcpy(__entry->hdr, hdr, sizeof(__entry->hdr));
+ memcpy(__entry->tsf, tsf, sizeof(__entry->tsf));
+ ),
+
+ TP_printk(
+ "%s: %s: HDR:%s, CDB:%s",
+ __get_str(str), __get_str(dev_name),
+ __print_hex(__entry->hdr, sizeof(__entry->hdr)),
+ __print_hex(__entry->tsf, sizeof(__entry->tsf))
+ )
+);
+
#endif /* if !defined(_TRACE_UFS_H) || defined(TRACE_HEADER_MULTI_READ) */
/* This part must
Re: Regression: kexec/kdump boot hangs with x86/vector commits
On 12/13/17 at 11:57pm, Yu Chen wrote: > On Wed, Dec 13, 2017 at 10:52:56AM +0800, Dave Young wrote: > > Hi, > > > > Kexec reboot and kdump has broken on my laptop for long time with > > 4.15.0-rc1+ kernels. With the patch below an early panic been fixed: > > https://patchwork.kernel.org/patch/10084289/ > > > > But still can not get a successful reboot, it looked like graphic > > issue, but after bisecting the kernel, I got below: > > > > [dyoung@dhcp-*-* linux]$ git bisect good > > There are only 'skip'ped commits left to test. > > The first bad commit could be any of: > > 2db1f959d9dc16035f2eb44ed5fdb2789b754d6a > > 4900be83602b6be07366d3e69f756c1959f4169a > > We cannot bisect more! > > > > These two commits can no be reverted because of code conflicts, thus > > I reverted the whole series from Thomas (below commits), with those > > x86/vector changes reverted, kexec reboot works fine. > > > > Could you help to take a look, any thoughts? I can do the test > > if you have some debug patch to try. > Is it possible that the "second" kernel runs on non-zero CPU? If yes, > what if some irqs are only delivered to cpu0? (use cpumask_of(0) > directly) Thanks for the reply. For kdump, yes, for kexec, I'm not sure. Here is some kexec kernel boot log: http://people.redhat.com/~ruyang/misc/kexec-regression.txt Copy the lockup call trace here: [ 23.779285] NMI watchdog: Watchdog detected hard LOCKUP on cpu 0 [ 23.779285] Modules linked in: arc4 rtsx_pci_sdmmc i915 iwlmvm kvm_intel mac8 0211 kvm irqbypass btusb btrtl btbcm intel_gtt btintel drm_kms_helper snd_hda_in tel syscopyarea bluetooth iwlwifi snd_hda_codec snd_hwdep snd_hda_core sysfillre ct snd_seq sysimgblt input_leds fb_sys_fops e1000e ecdh_generic cfg80211 snd_seq _device drm snd_pcm serio_raw ptp pcspkr thinkpad_acpi i2c_i801 snd_timer rtsx_p ci pps_core snd soundcore rfkill video [ 23.779307] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.15.0-rc3+ #378 [ 23.779308] Hardware name: LENOVO 20ARS1BJ02/20ARS1BJ02, BIOS GJET92WW (2.42 ) 03/03/2017 [ 23.779312] RIP: 0010:poll_idle+0x2f/0x5f [ 23.779313] RSP: 0018:81c03e80 EFLAGS: 0246 [ 23.779314] RAX: 81c0f4c0 RBX: 81c6db80 RCX: [ 23.779315] RDX: RSI: 81c6db80 RDI: 88021f2201e8 [ 23.779316] RBP: 88021f2201e8 R08: 00349a65b7dd R09: 88021f216db4 [ 23.779317] R10: 81c03e68 R11: R12: [ 23.779318] R13: 81c6db98 R14: R15: 000578a065b1 [ 23.779319] FS: () GS:88021f20() knlGS:0 000 [ 23.779320] CS: 0010 DS: ES: CR0: 80050033 [ 23.779321] CR2: 7ffed1d0ee60 CR3: 00021ec0a006 CR4: 001606b0 [ 23.779322] Call Trace: [ 23.779328] cpuidle_enter_state+0x6a/0x2c0 [ 23.779333] do_idle+0x17b/0x1d0 [ 23.779335] cpu_startup_entry+0x6f/0x80 [ 23.779338] start_kernel+0x431/0x451 [ 23.779342] secondary_startup_64+0xa5/0xb0 [ 23.779344] Code: 00 fb 66 0f 1f 44 00 00 65 48 8b 04 25 40 c4 00 00 f0 80 48 02 20 48 8b 08 83 e1 08 74 0d eb 12 f3 90 65 48 8b 04 25 40 c4 00 00 <48> 8b 00 a8 08 74 ee 65 48 8b 04 25 40 c4 00 00 f0 80 60 02 df Thanks Dave > > Thanks, > Yu >
Linux 4.9.69
I'm announcing the release of the 4.9.69 kernel. All users of the 4.9 kernel series must upgrade. The updated 4.9.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.9.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/devicetree/bindings/usb/usb-device.txt|2 Makefile|2 arch/arm/include/asm/assembler.h| 18 ++ arch/arm/include/asm/kvm_arm.h |4 arch/arm/include/asm/uaccess.h | 44 -- arch/arm/kernel/entry-header.S |6 arch/arm/kvm/handle_exit.c | 19 +- arch/arm/mach-omap2/gpmc-onenand.c | 10 - arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 25 ++- arch/arm64/include/asm/kvm_arm.h|3 arch/arm64/kernel/process.c |9 + arch/arm64/kvm/handle_exit.c| 19 +- arch/powerpc/Makefile | 11 + arch/powerpc/include/asm/checksum.h |2 arch/powerpc/kernel/cpu_setup_power.S |2 arch/powerpc/mm/pgtable-radix.c |4 arch/powerpc/platforms/powernv/pci-ioda.c |3 arch/powerpc/sysdev/axonram.c |5 arch/s390/kernel/syscalls.S |6 arch/s390/kvm/priv.c| 11 + arch/sparc/mm/init_64.c |9 + arch/x86/include/asm/kvm_host.h |3 arch/x86/kernel/hpet.c |2 arch/x86/kvm/vmx.c | 31 +--- arch/x86/kvm/x86.c | 14 ++ arch/x86/pci/broadcom_bus.c |2 arch/x86/platform/uv/tlb_uv.c |1 block/blk-core.c|4 block/blk-mq-sysfs.c|4 block/blk-mq.c |4 block/blk-mq.h |1 crypto/asymmetric_keys/pkcs7_verify.c |2 crypto/asymmetric_keys/x509_cert_parser.c |2 crypto/asymmetric_keys/x509_public_key.c|2 drivers/ata/libata-sff.c|1 drivers/atm/horizon.c |2 drivers/base/isa.c | 10 - drivers/block/zram/zram_drv.c |2 drivers/bus/arm-cci.c |7 - drivers/bus/arm-ccn.c | 11 + drivers/clk/uniphier/clk-uniphier-sys.c |2 drivers/crypto/s5p-sss.c|5 drivers/crypto/talitos.c| 66 ++--- drivers/edac/i5000_edac.c |8 - drivers/edac/i5400_edac.c |9 - drivers/firmware/efi/efi.c |3 drivers/firmware/efi/esrt.c | 17 +- drivers/firmware/efi/runtime-map.c | 10 - drivers/gpio/gpio-altera.c | 26 +-- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |5 drivers/gpu/drm/armada/Makefile |2 drivers/gpu/drm/exynos/exynos_drm_gem.c |9 + drivers/hid/Kconfig |4 drivers/hid/hid-chicony.c |1 drivers/hid/hid-core.c |1 drivers/hid/hid-ids.h |1 drivers/i2c/busses/i2c-riic.c |6 drivers/infiniband/hw/mlx4/qp.c |2 drivers/infiniband/hw/mlx5/main.c |2 drivers/iommu/intel-iommu.c |8 - drivers/irqchip/irq-crossbar.c |8 - drivers/media/rc/lirc_dev.c |4 drivers/media/usb/dvb-usb/dibusb-common.c | 16 ++ drivers/memory/omap-gpmc.c |4 drivers/net/can/ti_hecc.c |3 drivers/net/can/usb/ems_usb.c |2 drivers/net/can/usb/esd_usb2.c |2 drivers/net/can/usb/kvaser_usb.c| 13 + drivers/net/can/usb/usb_8dev.c |2 drivers/net/ethernet/broadcom/bnx2x/bnx2x_main
Re: Linux 4.9.69
diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt
b/Documentation/devicetree/bindings/usb/usb-device.txt
index 1c35e7b665e1..03ab8f5eab40 100644
--- a/Documentation/devicetree/bindings/usb/usb-device.txt
+++ b/Documentation/devicetree/bindings/usb/usb-device.txt
@@ -11,7 +11,7 @@ Required properties:
be used, but a device adhering to this binding may leave out all except
for usbVID,PID.
- reg: the port number which this device is connecting to, the range
- is 1-31.
+ is 1-255.
Example:
diff --git a/Makefile b/Makefile
index dfe17af517b2..8f2819bf8135 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 9
-SUBLEVEL = 68
+SUBLEVEL = 69
EXTRAVERSION =
NAME = Roaring Lionus
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index 68b06f9c65de..12f99fd2e3b2 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -516,4 +516,22 @@ THUMB( orr \reg , \reg , #PSR_T_BIT)
#endif
.endm
+ .macro bug, msg, line
+#ifdef CONFIG_THUMB2_KERNEL
+1: .inst 0xde02
+#else
+1: .inst 0xe7f001f2
+#endif
+#ifdef CONFIG_DEBUG_BUGVERBOSE
+ .pushsection .rodata.str, "aMS", %progbits, 1
+2: .asciz "\msg"
+ .popsection
+ .pushsection __bug_table, "aw"
+ .align 2
+ .word 1b, 2b
+ .hword \line
+ .popsection
+#endif
+ .endm
+
#endif /* __ASM_ASSEMBLER_H__ */
diff --git a/arch/arm/include/asm/kvm_arm.h b/arch/arm/include/asm/kvm_arm.h
index e22089fb44dc..98d6de177b7a 100644
--- a/arch/arm/include/asm/kvm_arm.h
+++ b/arch/arm/include/asm/kvm_arm.h
@@ -161,8 +161,7 @@
#else
#define VTTBR_X(5 - KVM_T0SZ)
#endif
-#define VTTBR_BADDR_SHIFT (VTTBR_X - 1)
-#define VTTBR_BADDR_MASK (((_AC(1, ULL) << (40 - VTTBR_X)) - 1) <<
VTTBR_BADDR_SHIFT)
+#define VTTBR_BADDR_MASK (((_AC(1, ULL) << (40 - VTTBR_X)) - 1) << VTTBR_X)
#define VTTBR_VMID_SHIFT _AC(48, ULL)
#define VTTBR_VMID_MASK(size) (_AT(u64, (1 << size) - 1) << VTTBR_VMID_SHIFT)
@@ -209,6 +208,7 @@
#define HSR_EC_IABT_HYP(0x21)
#define HSR_EC_DABT(0x24)
#define HSR_EC_DABT_HYP(0x25)
+#define HSR_EC_MAX (0x3f)
#define HSR_WFI_IS_WFE (_AC(1, UL) << 0)
diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
index 1f59ea051bab..b7e0125c0bbf 100644
--- a/arch/arm/include/asm/uaccess.h
+++ b/arch/arm/include/asm/uaccess.h
@@ -478,11 +478,10 @@ extern unsigned long __must_check
arm_copy_from_user(void *to, const void __user *from, unsigned long n);
static inline unsigned long __must_check
-__copy_from_user(void *to, const void __user *from, unsigned long n)
+__arch_copy_from_user(void *to, const void __user *from, unsigned long n)
{
unsigned int __ua_flags;
- check_object_size(to, n, false);
__ua_flags = uaccess_save_and_enable();
n = arm_copy_from_user(to, from, n);
uaccess_restore(__ua_flags);
@@ -495,18 +494,15 @@ extern unsigned long __must_check
__copy_to_user_std(void __user *to, const void *from, unsigned long n);
static inline unsigned long __must_check
-__copy_to_user(void __user *to, const void *from, unsigned long n)
+__arch_copy_to_user(void __user *to, const void *from, unsigned long n)
{
#ifndef CONFIG_UACCESS_WITH_MEMCPY
unsigned int __ua_flags;
-
- check_object_size(from, n, true);
__ua_flags = uaccess_save_and_enable();
n = arm_copy_to_user(to, from, n);
uaccess_restore(__ua_flags);
return n;
#else
- check_object_size(from, n, true);
return arm_copy_to_user(to, from, n);
#endif
}
@@ -526,25 +522,49 @@ __clear_user(void __user *addr, unsigned long n)
}
#else
-#define __copy_from_user(to, from, n) (memcpy(to, (void __force *)from, n), 0)
-#define __copy_to_user(to, from, n)(memcpy((void __force *)to, from, n), 0)
+#define __arch_copy_from_user(to, from, n) \
+ (memcpy(to, (void __force *)from, n), 0)
+#define __arch_copy_to_user(to, from, n) \
+ (memcpy((void __force *)to, from, n), 0)
#define __clear_user(addr, n) (memset((void __force *)addr, 0, n), 0)
#endif
-static inline unsigned long __must_check copy_from_user(void *to, const void
__user *from, unsigned long n)
+static inline unsigned long __must_check
+__copy_from_user(void *to, const void __user *from, unsigned long n)
+{
+ check_object_size(to, n, false);
+ return __arch_copy_from_user(to, from, n);
+}
+
+static inline unsigned long __must_check
+copy_from_user(void *to, const void __user *from, unsigned long n)
{
unsigned long res = n;
+
+ check_object_size(to, n, false);
+
if (likely(access_ok(VERIFY_READ, from, n)))
- res = __copy_from_user(to, from, n);
+ res = __arch_copy_from_user(to, from, n);
if (unlikely(res))
Re: [PATCH] driver core: Make it safe to use get_device() if the reference count is zero
On 2017/12/14 16:56, Greg KH wrote:
On Thu, Dec 14, 2017 at 04:27:56PM +0800, Jason Yan wrote:
On 2017/12/14 16:10, Greg KH wrote:
On Thu, Dec 14, 2017 at 03:56:46PM +0800, Jason Yan wrote:
On 2017/12/14 15:42, Greg KH wrote:
On Thu, Dec 14, 2017 at 11:39:36AM +0800, Jason Yan wrote:
Some driviers may have the chance to increase a reference count that
has dropped to zero when using get_device() because of their design.
Then those drivers are broken :)
We have met such a issue with scsi:
https://www.spinics.net/lists/linux-scsi/msg115295.html
The scsi core will keep the scsi device object in the host list after
it has been deleted and the iterator can still find it. All of the
places where need iterating have to check the state of the scsi device
and this makes a lot of code redundancy and complexity.
Provide a safe mechanism in get_device() by using
kobject_get_unless_zero().
Suggested-by: Bart Van Assche
Signed-off-by: Jason Yan
CC: Greg Kroah-Hartman
CC: Bart Van Assche
CC: Ewan D. Milne
CC: James E.J. Bottomley
CC: Christoph Hellwig
---
drivers/base/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 12ebd05..cc74810 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1916,7 +1916,7 @@ EXPORT_SYMBOL_GPL(device_register);
*/
struct device *get_device(struct device *dev)
{
- return dev ? kobj_to_dev(kobject_get(&dev->kobj)) : NULL;
+ return dev && kobject_get_unless_zero(&dev->kobj) ? dev : NULL;
I really don't want to do this, the bus the device is on should prevent
this from happening.
Also, once that reference count drops to zero, the memory should be
freed, so you really have a stale pointer here, and this code would fail
if you had slab debugging enabled anyway.
Actually I don't want this either. But the design of scsi core will leave
the scsi device on the host list after it is deleted, and it can be
found later and the refcount have a very big chance to increase from
zero again. And after a lot of discussion it seems that the scsi layer
is difficult to change the situation in the near future.
Keeping a 'struct device' reference counted chunk of memory on a list
that has a different lifetime rule from that device itself, is crazy.
The lifetime rule is the same. That device itself will delete from the
host list in the destructor, scsi_device_dev_release_usercontext(), and
the memory will be freed after that. That's why this issue came out.
And yes, I remember how all of this came about, but I really don't have
the time to work on it myself...
So I don't even think this fixes the issue you think it fixes :)
This issue is very easy to reproduce on my machine and I have tested the
patch and it really fixes the issue.
Even with slab debugging enabled? If so, what is keeping that memory
from being freed once the reference count drops to 0?
As above, the memory is not freed yet when we increasing the refconunt from
zero, so it's nothing to do with slab debugging enabled or not. If
we want to free it, we have to grab host lock first to delete it from
the list, so if we are grabing the host lock, we can increase the
refcount safely from 0 to 1.
Wait, what? Once that refcount goes to 0, the release callback will be
called, and the memory had better be freed. Any pointer you might still
have to the structure is now invalid. The fact that you are somehow
still keeping that pointer around is not ok, and slab debugging should
have caused the memory to be overwritten and garbage would result if you
tried to make this call again.
I don't know why scsi have this design. Anyone who is familiar with the
history of this design can explain this?
thanks,
greg k-h
.
Re: [PATCH] mm/mprotect: Add a cond_resched() inside change_pte_range()
On Thu 14-12-17 10:40:21, Anshuman Khandual wrote: [...] > diff --git a/mm/mprotect.c b/mm/mprotect.c > index ec39f73..4fce0f5 100644 > --- a/mm/mprotect.c > +++ b/mm/mprotect.c > @@ -144,6 +144,7 @@ static unsigned long change_pte_range(struct > vm_area_struct *vma, pmd_t *pmd, > } while (pte++, addr += PAGE_SIZE, addr != end); > arch_leave_lazy_mmu_mode(); > pte_unmap_unlock(pte - 1, ptl); > + cond_resched(); > > return pages; > } I would put this one level up to change_pmd_range to catch large THP backed regions. Something we do in zap_pmd_range. Other than that the patch makes sense to me. -- Michal Hocko SUSE Labs
Re: [alsa-devel] [PATCH v5] ASoC: TSCS42xx: Add support for Tempo Semiconductor's TSCS42xx audio CODEC
On Tue, Dec 12, 2017 at 03:31:16PM -0600, Steven Eckhoff wrote:
> On Tue, Dec 12, 2017 at 04:32:54PM +, Mark Brown wrote:
> > On Mon, Dec 11, 2017 at 01:54:25PM -0600, Steven Eckhoff wrote:
> > > +static int tscs42xx_probe(struct snd_soc_codec *codec)
> > > +{
> > > + int i;
> > > + int ret;
> > > +
> > > + for (i = 0; i < ARRAY_SIZE(r_inits); ++i) {
> > > + ret = snd_soc_write(codec, r_inits[i].reg, r_inits[i].def);
> > > + if (ret < 0) {
> > > + dev_err(codec->dev,
> > > + "Failed to write codec defaults (%d)\n", ret);
> > > + return ret;
> > > + }
> > > + }
> >
> > I'd expect the driver to just reset the CODEC (it appears to have that
> > feature) and the regmap.
> >
> These init values were meant to be driver defaults that differed from
> the device defaults. In hindsight this was a bad idea. I am removing
> them in the next revision and will have the machine driver setup the
> codec appropriately.
>
Not sure what you mean here but setting up CODEC registers
directly from the machine driver is probably not ideal. You
should probably be looking into regmap_register_patch this lets
you apply a bunch of register settings to the chip every time you
do a regmap_cache_sync. This is useful for situations like the
chip has terrible register defaults you want to correct.
Thanks,
Charles
Re: [BUG] acpica: ltp_acpi test case causes kernel crash at acpi_ns_walk_namespace
On Wed, Dec 13, 2017 at 05:52:38PM +0100, Rafael J. Wysocki wrote: > On Wed, Dec 13, 2017 at 3:55 PM, Vadim Lomovtsev > wrote: > > On Wed, Dec 13, 2017 at 12:45:50AM +0100, Rafael J. Wysocki wrote: > >> On Tuesday, December 12, 2017 4:59:19 PM CET Vadim Lomovtsev wrote: > >> > Hi guys, > >> > > >> > While running LTP tests I've faced kernel crash caused by ltp_acpi test > >> > case. > >> > I have ACPI support enabled in kernel but kernel is boot with FDT having > >> > ACPI > >> > disabled. The ltp_acpi test case application is built along with > >> > ltp_acpi_cmds > >> > module to run ACPI tests. > >> > > >> > So my question is - should we update acpica implementation at kernel > >> > side by > >> > adding 'acpi_disabled' variable checking to the 'acpi_get_devices' > >> > function (see > >> > patch next to this email, maybe not a good approach) or this should be > >> > fixed at LTP > >> > side so the ltp_acpi_cmds should be updated in order to check if acpi is > >> > enabled > >> > before running tests ? > >> > >> There should be a check preventing acpi_get_devices() from being called in > >> the > >> acpi_disabled case. > > > > In my case I have to update ltp_acpi code then. > > RIght. > > >> > >> acpi_disabled is Linux-specific and the ACPICA code isn't, so the code > >> calling > >> ACPICA functions should check acpi_disabled when necessary. > > > > Agree. However getting back to LTP tests it looks like such calls were > > implemented > > intentionally without checking of aspi_disabled value. > > > > Don't we have any self-testing stuff in acpica to prevent such scenarious ? > > ACPICA doesn't know anything about acpi_disabled as I said already. And I got it from the first time. And assuming that I said that suggested patch 'maybe not a good approach' in the issue description. Just wanted to highlight the issue and initiate discussion. > > I would argue that testing unsupported use cases in LTP is not very useful. > The ltp_acpi test in particular shows that there is no any protection from such actions so I wouldn't said that it is useless use case. From another hand, those calls were intialted from kernel module (which is part of test case) so the solution here is to place ACPI state check there - into kernel module. But again, see your point. Thank you for your time. > Thanks, > Rafael WBR, Vadim
Re: [PATCH] acpi: acpica: add acpi status check prior walking through namespace
On Wed, Dec 13, 2017 at 05:48:49PM +0100, Rafael J. Wysocki wrote: > On Wed, Dec 13, 2017 at 3:52 PM, Vadim Lomovtsev > wrote: > > On Tue, Dec 12, 2017 at 09:52:21PM +, Moore, Robert wrote: > >> Another way to look at this is that the kernel should not be calling ACPI > >> interfaces if ACPI is disabled. > > > > Yes, I agree. So in this case the ltp_acpi test case has to be updated with > > such checking > > before calling ACPI interfaces. However, it seems that such calls was put > > there intentionally, > > without ACPI state check, as part of kernel testing strategy. > > Not really. Ok, see your point. Thank you for your time. WBR, Vadim > > Thanks, > Rafael
Re: [PATCH v3 08/15] drm/sun4i: Add LVDS support
On Thu, Dec 14, 2017 at 11:30:21AM +0800, Chen-Yu Tsai wrote: > >> > + /* Map output pins to channel 0 */ > >> > + regmap_update_bits(tcon->regs, SUN4I_TCON_GCTL_REG, > >> > + SUN4I_TCON_GCTL_IOMAP_MASK, > >> > + SUN4I_TCON_GCTL_IOMAP_TCON0); > >> > + > >> > + /* Enable the output on the pins */ > >> > + regmap_write(tcon->regs, SUN4I_TCON0_IO_TRI_REG, 0xe000); > >> > >> Is this still needed? You are no longer using the TCON LCD pins > >> with LVDS. > > > > We do. It's a separate function of the pins, but it's the same pins. > > OK. I assume you've tried it without setting it and it failed? > I just assume that these refer to the TCON LCD output, whereas > LVDS looks like a separate module and function, and shouldn't > need it. Argh, I forgot to test that. I'll test it for real this time and will update that part with a comment if that's needed. Sorry :/ Maxime -- Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com signature.asc Description: PGP signature
Re: [PATCH] ACPI, APEI, Fix use resource_size
On Thu, Dec 14, 2017 at 12:07:30AM +0100, Rafael J. Wysocki wrote: > Which is exactly why you've got this question at all. ;-) So you're saying, you've got your minions to do review for you - you can lay back and play all managerial now, huh? :-P > OK, let's queue it up for 4.16, then. Yeah, just keep an eye on reports of mapping errors... -- Regards/Gruss, Boris. Good mailing practices for 400: avoid top-posting and trim the reply.
[PATCH] pinctrl: axp209: add missing Kconfig dependencies
This fixes some compilation issues.
GENERIC_PINCONF and OF at least for pinconf_generic_dt_*, PINMUX at
least for pinmux_ops and GPIOLIB for at least gpio_chip.
Fixes: 23f75d7dfa92 ("pinctrl: axp209: add pinctrl features")
Reported-by: Randy Dunlab
Signed-off-by: Quentin Schulz
---
drivers/pinctrl/Kconfig | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index ce126955212c..1dd445116432 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -66,6 +66,10 @@ config PINCTRL_AS3722
config PINCTRL_AXP209
tristate "X-Powers AXP209 PMIC pinctrl and GPIO Support"
depends on MFD_AXP20X
+ depends on OF
+ select PINMUX
+ select GENERIC_PINCONF
+ select GPIOLIB
help
AXP PMICs provides multiple GPIOs that can be muxed for different
functions. This driver bundles a pinctrl driver to select the function
--
2.14.1
RE: [PATCH 5/5] phy: renesas: rcar-gen3-usb2: add gpio handling
Hi Geert-san,
> From: Geert Uytterhoeven, Sent: Wednesday, December 13, 2017 5:55 PM
>
> Hi Shimoda-san,
>
> On Wed, Dec 13, 2017 at 7:27 AM, Yoshihiro Shimoda
> wrote:
> > Some R-Car SoCs (e.g. R-Car D3) doesn't have dedicated pins of VBUS
> > and ID. So, they may be connected to gpio pins. To handle the gpio
> > pins, this patch adds the handling of VBUS and ID pins instead of
> > dedicated pins.
> >
> > Signed-off-by: Yoshihiro Shimoda
> > ---
> > .../devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 2 +
> > drivers/phy/renesas/phy-rcar-gen3-usb2.c | 77
> > --
> > 2 files changed, 72 insertions(+), 7 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
> b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
> > index 99b651b..851582f 100644
> > --- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
> > +++ b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt
> > @@ -27,6 +27,8 @@ channel as USB OTG:
> > - interrupts: interrupt specifier for the PHY.
> > - vbus-supply: Phandle to a regulator that provides power to the VBUS. This
> >regulator will be managed during the PHY power on/off
> > sequence.
> > +- renesas,vbus-gpios: use gpio to control vbus instead of dedicated pin.
> > +- renesas,id-gpios: use gpio to detect id instead of dedicated pin.
>
> Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt already uses
> "vbus-gpios" and "id-gpios" without vendor-specific prefixes, so perhaps
> the "renesas," can be dropped?
Thank you for the comments. I agree with you. So, I'll drop "renesas," in v2.
Best regards,
Yoshihiro Shimoda
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
RE: [PATCH 2/5] phy: renesas: rcar-gen3-usb2: unify OBINTEN handling
Hello!
> From: Sergei Shtylyov, Sent: Wednesday, December 13, 2017 6:10 PM
>
> Hello!
>
> On 12/13/2017 9:27 AM, Yoshihiro Shimoda wrote:
>
> > This patch unifies the OBINTEN handling to clean-up the code.
> >
> > Signed-off-by: Yoshihiro Shimoda
> > ---
> > drivers/phy/renesas/phy-rcar-gen3-usb2.c | 23 +++
> > 1 file changed, 15 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> > b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> > index c22d65a..beeaa30 100644
> > --- a/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> > +++ b/drivers/phy/renesas/phy-rcar-gen3-usb2.c
> > @@ -147,6 +147,18 @@ static void rcar_gen3_enable_vbus_ctrl(struct
> > rcar_gen3_chan *ch, int vbus)
> > writel(val, usb2_base + USB2_ADPCTRL);
> > }
> >
> > +static void rcar_gen3_enable_otg_irq(struct rcar_gen3_chan *ch, int enable)
>
> If it both enables and disables, rcar_gen3_control_otg_irq() would seem a
> better name...
Thank you for the comment! I think so. So, I'll change the name in v2.
I'll also change the names of "enable_vbus_ctrl" and members of
rcar_gen3_role_swap_ops in the patch 4
Best regards,
Yoshihiro Shimoda
> > +{
> > + void __iomem *usb2_base = ch->base;
> > + u32 val = readl(usb2_base + USB2_OBINTEN);
> > +
> > + if (enable)
> > + val |= USB2_OBINT_BITS;
> > + else
> > + val &= ~USB2_OBINT_BITS;
> > + writel(val, usb2_base + USB2_OBINTEN);
> > +}
> > +
> > static void rcar_gen3_init_for_host(struct rcar_gen3_chan *ch)
> > {
> > rcar_gen3_set_linectrl(ch, 1, 1);
> [...]
>
> MBR, Sergei
Re: [PATCH 1/2] arm: dts: sun8i: a83t: remove leading zero from cpucfg node address
Hi,
On Wed, Dec 13, 2017 at 08:37:14PM +0100, Corentin Labbe wrote:
> This will fix the following warning:
> Warning (simple_bus_reg): Node /soc/cpucfg@0170 simple-bus unit address
> format error, expected "170"
>
> Signed-off-by: Corentin Labbe
> ---
> arch/arm/boot/dts/sun8i-a83t.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
> b/arch/arm/boot/dts/sun8i-a83t.dtsi
> index 7b372acf4bf6..715719f9ea2e 100644
> --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
> @@ -377,7 +377,7 @@
> #reset-cells = <1>;
> };
>
> - cpucfg@0170 {
> + cpucfg@170 {
> compatible = "allwinner,sun9i-a80-cpucfg";
> reg = <0x0170 0x100>;
That node isn't upstream.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
Re: [PATCH 2/2] arm: dts: sun8i: a83t: Add an unit address to the memory node
Hi,
On Wed, Dec 13, 2017 at 08:37:15PM +0100, Corentin Labbe wrote:
> This will fix the following warning:
> Warning (unit_address_vs_reg): Node /memory has a reg or ranges property, but
> no unit name
>
> Signed-off-by: Corentin Labbe
> ---
> arch/arm/boot/dts/sun8i-a83t.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
> b/arch/arm/boot/dts/sun8i-a83t.dtsi
> index 715719f9ea2e..bddde0141f24 100644
> --- a/arch/arm/boot/dts/sun8i-a83t.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
> @@ -160,7 +160,7 @@
> };
> };
>
> - memory {
> + memory@4000 {
> reg = <0x4000 0x8000>;
> device_type = "memory";
> };
Can't we just get rid of the memory node entirely? U-Boot will add it
for us anyway.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
Re: [PATCH v7 1/6] clk: meson: make the spinlock naming more specific
On Mon, 2017-12-11 at 22:13 +0800, Yixun Lan wrote: > Make the spinlock more specific, so better for lockdep > debugging and ctags/grep. > > Suggested-by: Stephen Boyd > Signed-off-by: Yixun Lan Applied to next/drivers Thx > > --- > > this patch try to address the issue which bring up by Stephen at [1] > [1] > http://lists.infradead.org/pipermail/linux-amlogic/2017-December/005534.html > --- > drivers/clk/meson/clkc.h| 2 +- > drivers/clk/meson/gxbb.c| 112 > ++-- > drivers/clk/meson/meson8b.c | 24 +- > 3 files changed, 69 insertions(+), 69 deletions(-)
Re: thinkpad x60: sound problems in 4.15-rc1 was Re: thinkpad x60: sound problems in 4.14.0-next-20171114
On Tue 2017-11-28 08:00:20, Takashi Iwai wrote: > On Mon, 27 Nov 2017 19:44:12 +0100, > Pavel Machek wrote: > > > > On Mon 2017-11-27 19:35:32, Takashi Iwai wrote: > > > On Mon, 27 Nov 2017 19:31:51 +0100, > > > Pavel Machek wrote: > > > > > > > > On Mon 2017-11-27 17:33:28, Takashi Iwai wrote: > > > > > On Mon, 27 Nov 2017 17:30:11 +0100, > > > > > Pavel Machek wrote: > > > > > > > > > > > > On Wed 2017-11-15 12:11:20, Pavel Machek wrote: > > > > > > > On Wed 2017-11-15 11:43:34, Takashi Iwai wrote: > > > > > > > > On Wed, 15 Nov 2017 11:05:33 +0100, > > > > > > > > Pavel Machek wrote: > > > > > > > > > > > > > > > > > > Hi! > > > > > > > > > > > > > > > > > > There are some sound problems in 4.14.0-next-20171114: > > > > > > > > > > > > > > > > > > mplayer shows pictures from video, but does not play. > > > > > > > > > > > > > > > > > > vlc plays video, but w/o sound > > > > > > > > > > > > > > > > > > mpg123 works. > > > > > > > > > > > > > > > > > > Hw is thinkpad X60. Any ideas? > > > > > > > > > > > > > > > > Nothing comes to my mind for now, sorry. > > > > > > > > > > > > > > > > Is it a regression, right? There are only few changes in both > > > > > > > > HD-audio and ALSA core sides, and they should be fairly > > > > > > > > harmless. > > > > > > > > > > > > > > Regression: yes. Reproducible: not sure. It went away after a > > > > > > > reboot > > > > > > > :-(. > > > > > > > > > > > > Reappeared, 4.15-rc1. > > > > > > > > > > > > [ 40.473822] PM: suspend exit > > > > > > [ 40.526027] sdhci-pci :15:00.2: Will use DMA mode even though > > > > > > HW doesn't fully claim to support it. > > > > > > [ 40.569765] e1000e: eth1 NIC Link is Down > > > > > > [ 40.578257] sdhci-pci :15:00.2: Will use DMA mode even though > > > > > > HW doesn't fully claim to support it. > > > > > > [ 40.648476] sdhci-pci :15:00.2: Will use DMA mode even though > > > > > > HW doesn't fully claim to support it. > > > > > > [ 40.737339] sdhci-pci :15:00.2: Will use DMA mode even though > > > > > > HW doesn't fully claim to support it. > > > > > > [ 43.018955] wlan0: authenticate with 00:00:00:00:00:01 > > > > > > [ 43.019072] wlan0: send auth to 00:00:00:00:00:01 (try 1/3) > > > > > > [ 43.023955] wlan0: authenticated > > > > > > [ 43.031721] wlan0: associate with 00:00:00:00:00:01 (try 1/3) > > > > > > [ 43.039733] wlan0: RX AssocResp from 00:00:00:00:00:01 > > > > > > (capab=0x401 > > > > > > status=0 aid=1) > > > > > > [ 43.042712] wlan0: associated > > > > > > [ 480.662456] snd_hda_intel :00:1b.0: IRQ timing workaround is > > > > > > activated for card #0. Suggest a bigger bdl_pos_adj. > > > > > > > > > > This message is often superfluous, so don't take this too seriously. > > > > > > > > > > > > > > > > pavel@amd:~$ > > > > > > > > > > > > Again, mplayer has problems, mpg123 works. This time mplayer started > > > > > > playing video (w/o sound) after long delay. > > > > > > > > > > > > Uh. huh. And now problems appeared in mpg123, too, and then went > > > > > > away > > > > > > in mpg123 _and_ mplayer. Interesting. > > > > > > > > > > > > I suspect some pulseaudio fun. chromium always has sound problems, > > > > > > then I restart chromium and everything is ok. But something changed > > > > > > in > > > > > > -next and 4.15-rc1, because mplayer did not have problems before. > > > > > > > > > > Hm, there is no code change at all in sound/*. If it happens only in > > > > > linux-next, it must be something else... > > > > > > > > It happened first in -next, now it is in 4.15-rc1. > > > > > > So you meant a possible regression between 4.14 and 4.15-rc1? > > > > Yes. > > Hm, as far as I see, the only significant difference is the commit > 20e3f985bb875fea4f86b04eba4b6cc29bfd6b71 > ALSA: pcm: update tstamp only if audio_tstamp changed > > Another change d6c0615f510bc1ee26cfb2b9a3343ac99b9c46fb > ALSA: hda - Fix yet remaining issue with vmaster 0dB > initialization > is basically for fixing a previous wrong fix, and it should influence > on all use cases, not only for a specific application. Happened again, this time on -rc3. It is more than "audio is silent" -- apps behave strangely. Let me test with 20e3f985bb875fea4f86b04eba4b6cc29bfd6b71 reverted. Hmm. This is 4th regression this release cycle :-(. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH v7 3/6] clk: meson-axg: add clocks dt-bindings required header
On Mon, 2017-12-11 at 22:13 +0800, Yixun Lan wrote: > From: Qiufang Dai > > Add the required header for the clocks ID dt-bindings > exported from various subsystem in the Meson-AXG SoC. > > Acked-by: Rob Herring > Signed-off-by: Qiufang Dai > Signed-off-by: Yixun Lan Applied to next/dt Thx > --- > include/dt-bindings/clock/axg-clkc.h | 71 > > 1 file changed, 71 insertions(+) > create mode 100644 include/dt-bindings/clock/axg-clkc.h
Re: [PATCH v7 2/6] dt-bindings: clock: add compatible variant for the Meson-AXG
On Mon, 2017-12-11 at 22:13 +0800, Yixun Lan wrote: > Update the documentation to support clock driver for the Amlogic's > Meson-AXG SoC. > > Acked-by: Rob Herring > Signed-off-by: Yixun Lan Applied to next/dt Thx > --- > Documentation/devicetree/bindings/clock/amlogic,gxbb-clkc.txt | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-)
Re: [PATCH v7 4/6] clk: meson-axg: add clock controller drivers
On Mon, 2017-12-11 at 22:13 +0800, Yixun Lan wrote: > From: Qiufang Dai > > Add clock controller drivers for Amlogic Meson-AXG SoC. > > Acked-by: Neil Armstrong > Signed-off-by: Qiufang Dai > Signed-off-by: Yixun Lan Applied to next/drivers Thx > --- > arch/arm64/Kconfig.platforms | 1 + > drivers/clk/meson/Kconfig| 8 + > drivers/clk/meson/Makefile | 1 + > drivers/clk/meson/axg.c | 936 > +++ > drivers/clk/meson/axg.h | 126 ++ > 5 files changed, 1072 insertions(+) > create mode 100644 drivers/clk/meson/axg.c > create mode 100644 drivers/clk/meson/axg.h
RE: [PATCH v4 00/12] [dt-bindings] [media] Add document file and driver for Sony CXD2880 DVB-T2/T tuner + demodulator
Dear Mauro Thanks for your review. We will refer to your comments and consider how to respond for them. I want to confirm one thing about SPDX license text We will add SPDX license text to our files, Is it necessary to add SPDX not only .c .h Makefile but also Kconfig? When I checked current files in driver/media, there is no Kconfig file which has SPDX. Best Regards, Takiguchi
Re: [PATCH v7 0/6] add clk controller driver for Meson-AXG SoC
On Mon, 2017-12-11 at 22:13 +0800, Yixun Lan wrote: > Qiufang Dai (3): > clk: meson-axg: add clocks dt-bindings required header > clk: meson-axg: add clock controller drivers > arm64: dts: meson-axg: add clock DT info for Meson AXG SoC > > Yixun Lan (3): > clk: meson: make the spinlock naming more specific > dt-bindings: clock: add compatible variant for the Meson-AXG > arm64: dts: meson-axg: switch uart_ao clock to CLK81 > > .../bindings/clock/amlogic,gxbb-clkc.txt | 7 +- > arch/arm64/Kconfig.platforms | 1 + > arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 2 + > arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 19 +- > drivers/clk/meson/Kconfig | 8 + > drivers/clk/meson/Makefile | 1 + > drivers/clk/meson/axg.c| 936 > + > drivers/clk/meson/axg.h| 126 +++ > drivers/clk/meson/clkc.h | 2 +- > drivers/clk/meson/gxbb.c | 112 +-- > drivers/clk/meson/meson8b.c| 24 +- > include/dt-bindings/clock/axg-clkc.h | 71 ++ > 12 files changed, 1234 insertions(+), 75 deletions(-) > create mode 100644 drivers/clk/meson/axg.c > create mode 100644 drivers/clk/meson/axg.h > create mode 100644 include/dt-bindings/clock/axg-clkc.h Kevin, I took the first 4 patches through clk-meson. I left the last 2 for you. I have applied the DT bindings update separately. Let me know if you have dependency on these new bindings and need a tag. Cheers Jerome
[PATCH V2] KVM/x86: Check input paging mode when cs.l is set
Reported by syzkaller:
WARNING: CPU: 0 PID: 27962 at arch/x86/kvm/emulate.c:5631
x86_emulate_insn+0x557/0x15f0 [kvm]
Modules linked in: kvm_intel kvm [last unloaded: kvm]
CPU: 0 PID: 27962 Comm: syz-executor Tainted: GB W
4.15.0-rc2-next-20171208+ #32
Hardware name: Intel Corporation S1200SP/S1200SP, BIOS
S1200SP.86B.01.03.0006.040720161253 04/07/2016
RIP: 0010:x86_emulate_insn+0x557/0x15f0 [kvm]
RSP: 0018:8807234476d0 EFLAGS: 00010282
RAX: RBX: 88072d0237a0 RCX: a0065c4d
RDX: 1100e5a046f9 RSI: 0003 RDI: 88072d0237c8
RBP: 880723447728 R08: 88072d02 R09: a008d240
R10: 0002 R11: ed00e7d87db3 R12: 88072d0237c8
R13: 88072d023870 R14: 88072d0238c2 R15: a008d080
FS: 7f8a68666700() GS:88080220() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 2009506c CR3: 00071fec4005 CR4: 003626f0
Call Trace:
x86_emulate_instruction+0x3bc/0xb70 [kvm]
? reexecute_instruction.part.162+0x130/0x130 [kvm]
vmx_handle_exit+0x46d/0x14f0 [kvm_intel]
? trace_event_raw_event_kvm_entry+0xe7/0x150 [kvm]
? handle_vmfunc+0x2f0/0x2f0 [kvm_intel]
? wait_lapic_expire+0x25/0x270 [kvm]
vcpu_enter_guest+0x720/0x1ef0 [kvm]
...
When CS.L is set, vcpu should run in the 64 bit paging mode.
Current kvm set_sregs function doesn't have such check when
userspace inputs sreg values. This will lead unexpected behavior.
This patch is to add checks for CS.L, EFER.LME, EFER.LMA and
CR4.PAE when get SREG inputs from userspace in order to avoid
unexpected behavior.
Suggested-by: Paolo Bonzini
Reported-by: Dmitry Vyukov
Cc: Paolo Bonzini
Cc: Radim Krčmář
Cc: Dmitry Vyukov
Cc: Jim Mattson
Signed-off-by: Tianyu Lan
---
Change since v1:
Add check for EFER.LME, EFER.LMA and CR4.PAE
in order to make sure that if EFER.LME=1 and CR0.PG=1,
EFER.LMA and CR4.PAE must be 1.
---
arch/x86/kvm/x86.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 1e1e617..8aca950 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -7485,6 +7485,30 @@ int kvm_task_switch(struct kvm_vcpu *vcpu, u16
tss_selector, int idt_index,
}
EXPORT_SYMBOL_GPL(kvm_task_switch);
+int kvm_valid_sregs(struct kvm_vcpu *vcpu, struct kvm_sregs *sregs)
+{
+ /*
+* When EFER.LME and CR0.PG are set, CR4.PAE and EFER.LMA
+* must be set.
+*/
+ if ((sregs->efer & EFER_LME) && (sregs->cr0 & X86_CR0_PG_BIT)) {
+ if (!(sregs->cr4 & X86_CR4_PAE_BIT))
+ return -EINVAL;
+ if (!(sregs->efer & EFER_LMA))
+ return -EINVAL;
+ } else if (sregs->efer & EFER_LMA)
+ return -EINVAL;
+
+ /* When CS.L is set, vcpu should run in 64-bit mode. */
+ if (sregs->cs.l)
+ if (!((sregs->cr0 & X86_CR0_PG_BIT) &&
+ (sregs->cr4 & X86_CR4_PAE_BIT) &&
+ (sregs->efer & EFER_LME)))
+ return -EINVAL;
+
+ return 0;
+}
+
int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
struct kvm_sregs *sregs)
{
@@ -7497,6 +7521,9 @@ int kvm_arch_vcpu_ioctl_set_sregs(struct kvm_vcpu *vcpu,
(sregs->cr4 & X86_CR4_OSXSAVE))
return -EINVAL;
+ if (kvm_valid_sregs(vcpu, sregs))
+ return -EINVAL;
+
apic_base_msr.data = sregs->apic_base;
apic_base_msr.host_initiated = true;
if (kvm_set_apic_base(vcpu, &apic_base_msr))
--
1.8.3.1
[PATCH net-next v6 0/2] add UniPhier AVE ethernet support
This series adds support for Socionext AVE ethernet controller implemented
on UniPhier SoCs. This driver supports RGMII/RMII modes.
v5: https://www.spinics.net/lists/netdev/msg471330.html
The PHY patch included in v1 has already separated in:
http://www.spinics.net/lists/netdev/msg454595.html
Changes since v5:
- replace license boilerplate with SPDX Identifier
- remove inline directives and an unused function
Changes since v4:
- fix larger integer warning on AVE_PFMBYTE_MASK0
Changes since v3:
- remove checking dma address and use dma_set_mask() to restirct address
- replace ave_mdio_busywait() with read_poll_timeout()
- replace functions to access to registers with readl/writel() directly
- replace a function to access to macaddr with ave_hw_write_macaddr()
- change return value of ave_dma_map() to error value
- move mdiobus_unregister() from ave_remove() to ave_uninit()
- eliminate else block at the end of ave_dma_map()
- add mask definitions for packet filter
- sort bitmap definitions in descending order
- add error check to some functions
- rename and sort functions to clear sub-categories
- fix error value consistency
- remove unneeded initializers
- change type of constant arrays
Changes since v2:
- replace clk_get() with devm_clk_get()
- replace reset_control_get() with devm_reset_control_get_optional_shared()
- add error return when the error occurs on the above *_get functions
- sort soc data and compatible strings
- remove clearly obvious comments
- modify dt-bindings document consistent with these modifications
Changes since v1:
- add/remove devicetree properties and sub-node
- remove "internal-phy-interrupt" and "desc-bits" property
- add SoC data structures based on compatible strings
- add node operation to apply "mdio" sub-node
- add support for features
- add support for {get,set}_pauseparam and pause frame operations
- add support for ndo_get_stats64 instead of ndo_get_stats
- replace with desiable functions
- replace check for valid phy_mode with phy_interface{_mode}_is_rgmii()
- replace phy attach message with phy_attached_info()
- replace 32bit operation with {upper,lower}_32_bits() on ave_wdesc_addr()
- replace nway_reset and get_link with generic functions
- move operations to proper functions
- move phy_start_aneg() to ndo_open,
and remove unnecessary PHY interrupt operations
See http://www.spinics.net/lists/netdev/msg454590.html
- move irq initialization and descriptor memory allocation to ndo_open
- move initialization of reset and clock and mdiobus to ndo_init
- fix skbuffer operations
- fix skb alignment operations and add Rx buffer adjustment for descriptor
See http://www.spinics.net/lists/netdev/msg456014.html
- add error returns when dma_map_single() failed
- clean up code structures
- clean up wait-loop and wake-queue conditions
- add ave_wdesc_addr() and offset definitions
- add ave_macaddr_init() to clean up mac-address operation
- fix checking whether Tx entry is not enough
- fix supported features of phydev
- add necessary free/disable operations
- add phydev check on ave_{get,set}_wol()
- remove netif_carrier functions, phydev initializer, and Tx budget check
- change obsolate codes
- replace ndev->{base_addr,irq} with the members of ave_private
- rename goto labels and mask definitions, and remove unused codes
Kunihiko Hayashi (2):
dt-bindings: net: add DT bindings for Socionext UniPhier AVE
net: ethernet: socionext: add AVE ethernet driver
.../bindings/net/socionext,uniphier-ave4.txt | 48 +
drivers/net/ethernet/Kconfig |1 +
drivers/net/ethernet/Makefile |1 +
drivers/net/ethernet/socionext/Kconfig | 22 +
drivers/net/ethernet/socionext/Makefile|5 +
drivers/net/ethernet/socionext/sni_ave.c | 1727
6 files changed, 1804 insertions(+)
create mode 100644
Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt
create mode 100644 drivers/net/ethernet/socionext/Kconfig
create mode 100644 drivers/net/ethernet/socionext/Makefile
create mode 100644 drivers/net/ethernet/socionext/sni_ave.c
--
2.7.4
[PATCH net-next v6 2/2] net: ethernet: socionext: add AVE ethernet driver
The UniPhier platform from Socionext provides the AVE ethernet controller that includes MAC and MDIO bus supporting RGMII/RMII modes. The controller is named AVE. Signed-off-by: Kunihiko Hayashi Signed-off-by: Jassi Brar Reviewed-by: Andrew Lunn --- drivers/net/ethernet/Kconfig |1 + drivers/net/ethernet/Makefile|1 + drivers/net/ethernet/socionext/Kconfig | 22 + drivers/net/ethernet/socionext/Makefile |5 + drivers/net/ethernet/socionext/sni_ave.c | 1727 ++ 5 files changed, 1756 insertions(+) create mode 100644 drivers/net/ethernet/socionext/Kconfig create mode 100644 drivers/net/ethernet/socionext/Makefile create mode 100644 drivers/net/ethernet/socionext/sni_ave.c diff --git a/drivers/net/ethernet/Kconfig b/drivers/net/ethernet/Kconfig index c604213..d50519e 100644 --- a/drivers/net/ethernet/Kconfig +++ b/drivers/net/ethernet/Kconfig @@ -170,6 +170,7 @@ source "drivers/net/ethernet/sis/Kconfig" source "drivers/net/ethernet/sfc/Kconfig" source "drivers/net/ethernet/sgi/Kconfig" source "drivers/net/ethernet/smsc/Kconfig" +source "drivers/net/ethernet/socionext/Kconfig" source "drivers/net/ethernet/stmicro/Kconfig" source "drivers/net/ethernet/sun/Kconfig" source "drivers/net/ethernet/tehuti/Kconfig" diff --git a/drivers/net/ethernet/Makefile b/drivers/net/ethernet/Makefile index 39f62733..6cf5ade 100644 --- a/drivers/net/ethernet/Makefile +++ b/drivers/net/ethernet/Makefile @@ -82,6 +82,7 @@ obj-$(CONFIG_SFC) += sfc/ obj-$(CONFIG_SFC_FALCON) += sfc/falcon/ obj-$(CONFIG_NET_VENDOR_SGI) += sgi/ obj-$(CONFIG_NET_VENDOR_SMSC) += smsc/ +obj-$(CONFIG_NET_VENDOR_SOCIONEXT) += socionext/ obj-$(CONFIG_NET_VENDOR_STMICRO) += stmicro/ obj-$(CONFIG_NET_VENDOR_SUN) += sun/ obj-$(CONFIG_NET_VENDOR_TEHUTI) += tehuti/ diff --git a/drivers/net/ethernet/socionext/Kconfig b/drivers/net/ethernet/socionext/Kconfig new file mode 100644 index 000..3a1829e --- /dev/null +++ b/drivers/net/ethernet/socionext/Kconfig @@ -0,0 +1,22 @@ +config NET_VENDOR_SOCIONEXT + bool "Socionext ethernet drivers" + default y + ---help--- + Option to select ethernet drivers for Socionext platforms. + + Note that the answer to this question doesn't directly affect the + kernel: saying N will just cause the configurator to skip all + the questions about Socionext devices. If you say Y, you will be asked + for your specific card in the following questions. + +if NET_VENDOR_SOCIONEXT + +config SNI_AVE + tristate "Socionext AVE ethernet support" + depends on (ARCH_UNIPHIER || COMPILE_TEST) && OF + select PHYLIB + ---help--- + Driver for gigabit ethernet MACs, called AVE, in the + Socionext UniPhier family. + +endif #NET_VENDOR_SOCIONEXT diff --git a/drivers/net/ethernet/socionext/Makefile b/drivers/net/ethernet/socionext/Makefile new file mode 100644 index 000..ab83df6 --- /dev/null +++ b/drivers/net/ethernet/socionext/Makefile @@ -0,0 +1,5 @@ +# SPDX-License-Identifier: GPL-2.0 +# +# Makefile for all ethernet ip drivers on Socionext platforms +# +obj-$(CONFIG_SNI_AVE) += sni_ave.o diff --git a/drivers/net/ethernet/socionext/sni_ave.c b/drivers/net/ethernet/socionext/sni_ave.c new file mode 100644 index 000..15f975e --- /dev/null +++ b/drivers/net/ethernet/socionext/sni_ave.c @@ -0,0 +1,1727 @@ +// SPDX-License-Identifier: GPL-2.0 +/** + * sni_ave.c - Socionext UniPhier AVE ethernet driver + * Copyright 2014 Panasonic Corporation + * Copyright 2015-2017 Socionext Inc. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* General Register Group */ +#define AVE_IDR0x000 /* ID */ +#define AVE_VR 0x004 /* Version */ +#define AVE_GRR0x008 /* Global Reset */ +#define AVE_CFGR 0x00c /* Configuration */ + +/* Interrupt Register Group */ +#define AVE_GIMR 0x100 /* Global Interrupt Mask */ +#define AVE_GISR 0x104 /* Global Interrupt Status */ + +/* MAC Register Group */ +#define AVE_TXCR 0x200 /* TX Setup */ +#define AVE_RXCR 0x204 /* RX Setup */ +#define AVE_RXMAC1R0x208 /* MAC address (lower) */ +#define AVE_RXMAC2R0x20c /* MAC address (upper) */ +#define AVE_MDIOCTR0x214 /* MDIO Control */ +#define AVE_MDIOAR 0x218 /* MDIO Address */ +#define AVE_MDIOWDR0x21c /* MDIO Data */ +#define AVE_MDIOSR 0x220 /* MDIO Status */ +#define AVE_MDIORDR0x224 /* MDIO Rd Data */ + +/* Descriptor Control Register Group */ +#define AVE_DESCC 0x300 /* Descriptor Control */ +#define AVE_TXDC 0x304 /* TX Descriptor Configuration */ +#define AVE_RXDC0 0x308 /*
[PATCH net-next v6 1/2] dt-bindings: net: add DT bindings for Socionext UniPhier AVE
DT bindings for the AVE ethernet controller found on Socionext's
UniPhier platforms.
Signed-off-by: Kunihiko Hayashi
Signed-off-by: Jassi Brar
Acked-by: Rob Herring
---
.../bindings/net/socionext,uniphier-ave4.txt | 48 ++
1 file changed, 48 insertions(+)
create mode 100644
Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt
diff --git a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt
b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt
new file mode 100644
index 000..4700377
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.txt
@@ -0,0 +1,48 @@
+* Socionext AVE ethernet controller
+
+This describes the devicetree bindings for AVE ethernet controller
+implemented on Socionext UniPhier SoCs.
+
+Required properties:
+ - compatible: Should be
+ - "socionext,uniphier-pro4-ave4" : for Pro4 SoC
+ - "socionext,uniphier-pxs2-ave4" : for PXs2 SoC
+ - "socionext,uniphier-ld11-ave4" : for LD11 SoC
+ - "socionext,uniphier-ld20-ave4" : for LD20 SoC
+ - reg: Address where registers are mapped and size of region.
+ - interrupts: Should contain the MAC interrupt.
+ - phy-mode: See ethernet.txt in the same directory. Allow to choose
+ "rgmii", "rmii", or "mii" according to the PHY.
+ - phy-handle: Should point to the external phy device.
+ See ethernet.txt file in the same directory.
+ - clocks: A phandle to the clock for the MAC.
+
+Optional properties:
+ - resets: A phandle to the reset control for the MAC
+ - local-mac-address: See ethernet.txt in the same directory.
+
+Required subnode:
+ - mdio: Device tree subnode with the following required properties:
+ - #address-cells: Must be <1>.
+ - #size-cells: Must be <0>.
+ - reg: phy ID number, usually a small integer.
+
+Example:
+
+ ether: ethernet@6500 {
+ compatible = "socionext,uniphier-ld20-ave4";
+ reg = <0x6500 0x8500>;
+ interrupts = <0 66 4>;
+ phy-mode = "rgmii";
+ phy-handle = <ðphy>;
+ clocks = <&sys_clk 6>;
+ resets = <&sys_rst 6>;
+ local-mac-address = [00 00 00 00 00 00];
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ethphy: ethphy@1 {
+ reg = <1>;
+ };
+ };
+ };
--
2.7.4
Re: [BUG] sound/soc/samsung: a possible sleep-in-atomic bugs in s3c_pcm_hw_params
On Tue, Dec 12, 2017 at 2:24 AM, Jia-Ju Bai wrote: > According to sound/soc/samsung/pcm.c, the kernel module may sleep under a > spinlock. > The function call path is: > s3c_pcm_hw_params (acquire the spinlock) > clk_get_rate > clk_core_get_rate > clk_prepare_lock > mutex_lock --> may sleep > > I do not find a good way to fix it, so I only report. > This possible bug is found by my static analysis tool (DSAC) and my code > review. Thanks for the report. Your finding looks correct, the code might sleep under spinlock. I do not see easy solution. Maybe the readl(regs + S3C_PCM_CLKCTL) and clk_get_rate() could be moved before spinlock. The second path modifying it - s3c_pcm_set_sysclk() - is not protected by it. The spinlock is not effective around it. Best regards, Krzysztof
Re: [PATCH v7 0/6] add clk controller driver for Meson-AXG SoC
Hi Jerome & Kevin On 12/14/17 18:03, Jerome Brunet wrote: > On Mon, 2017-12-11 at 22:13 +0800, Yixun Lan wrote: >> Qiufang Dai (3): >> clk: meson-axg: add clocks dt-bindings required header >> clk: meson-axg: add clock controller drivers >> arm64: dts: meson-axg: add clock DT info for Meson AXG SoC >> >> Yixun Lan (3): >> clk: meson: make the spinlock naming more specific >> dt-bindings: clock: add compatible variant for the Meson-AXG >> arm64: dts: meson-axg: switch uart_ao clock to CLK81 >> >> .../bindings/clock/amlogic,gxbb-clkc.txt | 7 +- >> arch/arm64/Kconfig.platforms | 1 + >> arch/arm64/boot/dts/amlogic/meson-axg-s400.dts | 2 + >> arch/arm64/boot/dts/amlogic/meson-axg.dtsi | 19 +- >> drivers/clk/meson/Kconfig | 8 + >> drivers/clk/meson/Makefile | 1 + >> drivers/clk/meson/axg.c| 936 >> + >> drivers/clk/meson/axg.h| 126 +++ >> drivers/clk/meson/clkc.h | 2 +- >> drivers/clk/meson/gxbb.c | 112 +-- >> drivers/clk/meson/meson8b.c| 24 +- >> include/dt-bindings/clock/axg-clkc.h | 71 ++ >> 12 files changed, 1234 insertions(+), 75 deletions(-) >> create mode 100644 drivers/clk/meson/axg.c >> create mode 100644 drivers/clk/meson/axg.h >> create mode 100644 include/dt-bindings/clock/axg-clkc.h > > Kevin, > > I took the first 4 patches through clk-meson. I left the last 2 for you. > > I have applied the DT bindings update separately. > Let me know if you have dependency on these new bindings and need a tag. > thanks for taking care of this.. I think it's a good idea to make a tag, if peripheral driver request clock, then the DT part patch will need include/dt-bindings/clock/axg-clkc.h to build successfully. Yixun
Re: [PATCH 3/5] media: i2c: Add TDA1997x HDMI receiver driver
On 14/12/17 00:33, Tim Harvey wrote: > On Tue, Dec 12, 2017 at 4:18 AM, Hans Verkuil wrote: >> Hi Tim, >> >> Sorry for the delay, I needed to find some time to think about this. >> >> On 11/16/17 05:30, Rob Herring wrote: >>> On Wed, Nov 15, 2017 at 10:31:14AM -0800, Tim Harvey wrote: On Wed, Nov 15, 2017 at 7:52 AM, Rob Herring wrote: > On Thu, Nov 09, 2017 at 10:45:34AM -0800, Tim Harvey wrote: >> Add support for the TDA1997x HDMI receivers. >> >> Cc: Hans Verkuil >> Signed-off-by: Tim Harvey >> --- >> v3: >> - use V4L2_DV_BT_FRAME_WIDTH/HEIGHT macros >> - fixed missing break >> - use only hdmi_infoframe_log for infoframe logging >> - simplify tda1997x_s_stream error handling >> - add delayed work proc to handle hotplug enable/disable >> - fix set_edid (disable HPD before writing, enable after) >> - remove enabling edid by default >> - initialize timings >> - take quant range into account in colorspace conversion >> - remove vendor/product tracking (we provide this in log_status via >> infoframes) >> - add v4l_controls >> - add more detail to log_status >> - calculate vhref generator timings >> - timing detection fixes (rounding errors, hswidth errors) >> - rename configure_input/configure_conv functions >> >> v2: >> - implement dv timings enum/cap >> - remove deprecated g_mbus_config op >> - fix dv_query_timings >> - add EDID get/set handling >> - remove max-pixel-rate support >> - add audio codec DAI support >> - change audio bindings >> --- >> drivers/media/i2c/Kconfig|9 + >> drivers/media/i2c/Makefile |1 + >> drivers/media/i2c/tda1997x.c | 3485 >> ++ >> include/dt-bindings/media/tda1997x.h | 78 + > > This belongs with the binding documentation patch. > Rob, Thanks - missed that. I will move it for v4. Regarding your previous comment to the v2 series: > The rest of the binding looks fine, but I have some reservations about > this. I think this should be common probably. There's been a few > bindings for display recently that deal with the interface format. Maybe > some vendor property is needed here to map a standard interface format > back to pin configuration. I take it this is not an 'Ack' for the bindings? Which did you feel should be made common? I admit I was surprised there wasn't a common binding for audio bus format (i2s|spdif) but if you were referring to the video data that would probably be much more complicated. >>> >>> The video data. Either you have to try to come up with some way to map >>> color components to signals/pins (and even cycles) or you just enumerate >>> the formats and keep adding to them when new ones appear. There's h/w >>> that allows the former, but in the end you have to interoperate, so >>> enumerating the formats is probably enough. >>> I was hoping one of the media/driver maintainers would respond to your comment with thoughts as I'm not familiar with a very wide variety of receivers. >>> >>> I am hoping, too. >> >> I don't think it is right to store this in the DT. How you map the output >> pins >> is a driver thing. So when you are requested to enumerate the mediabus >> formats >> (include/uapi/linux/media-bus-format.h) you support, you do so based on the >> capabilities of the hardware, and when a format is requested you program the >> hardware accordingly. >> >> The device tree should describe the physical characteristics like the number >> of pins that are hooked up (i.e. are there 24, 30 or 36 pins connected). >> >> These vidout-portcfg mappings do not appear to describe physical properties >> but really register settings. > > Hans, > > They are register settings that define which bits on the internal data > bus are mapped to which pins on the package. Internally these parts > have a 36bit video data bus but externally the tda19971 only has 24 > pins and even then perhaps only 8 are hooked up if using BT656 and the > registers also define 'which 8' as it could have been connected to the > upper or lower part of the bus. So while the bindings from > video-interfaces.txt provide bus-width and details of the sync > signals, additional hardware-specific interconnect details such as how > the video bits are shifted/mixed on the output bus are needed here. > This is why I feel vidout-portcfg should be a dt property vs something > like a module param. The video-interfaces.txt bindings text defines bus-width and data-shift. The last one would define 'which 8'. Only if the hardware can do weird stuff like using pins 4-7 and 16-19 would this be insufficient. But in that case we would need something more detailed in video-interfaces.txt. Frankly, unless you've seen anyone do something weird like t
[PATCH] mt76: fix memcpy to potential null pointer on failed allocation
From: Colin Ian King
Currently if the allocation of skb fails and returns NULL then the
call to skb_put will cause a null pointer dereference. Fix this by
checking for a null skb and returning NULL. Note that calls to
function mt76x2_mcu_msg_alloc don't directly check the null return
but instead pass the NULL pointer to mt76x2_mcu_msg_send which
checks for the NULL and returns ENOMEM in this case.
Detected by CoverityScan, CID#1462624 ("Dereference null return value")
Fixes: 7bc04215a66b ("mt76: add driver code for MT76x2e")
Signed-off-by: Colin Ian King
---
drivers/net/wireless/mediatek/mt76/mt76x2_mcu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2_mcu.c
b/drivers/net/wireless/mediatek/mt76/mt76x2_mcu.c
index d45737ee1412..15820b11f9db 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x2_mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x2_mcu.c
@@ -45,6 +45,8 @@ static struct sk_buff *mt76x2_mcu_msg_alloc(const void *data,
int len)
struct sk_buff *skb;
skb = alloc_skb(len, GFP_KERNEL);
+ if (!skb)
+ return NULL;
memcpy(skb_put(skb, len), data, len);
return skb;
--
2.14.1
Re: [PATCH] PCI: qcom: add missing supplies required for msm8996
Hi Srini,
On 12/08/2017 11:20 AM, srinivas.kandaga...@linaro.org wrote:
> From: Srinivas Kandagatla
>
> This patch adds supplies that are required for msm8996. Two of them vdda
> and vdda-1p8 are analog supplies that go in to controller, and the rest
According to the msm8996 device specification there are two pins related
to the PCIe power: VDD_PCIE_CORE (power for PCIe core circuitry) and
VDD_PCIE_1P8 (power for PCIe I/O circuitry). Thus I think it is clear
that VDD_PCIE_CORE is vdda and VDD_PCIE_1P8 should be part of PCIe phy
driver DT binding (and this is the case currently [1]). So I don't think
we need vdda-1p8 regulator DT binding for that in pcie-qcom.
> of the two vddpe's are supplies to PCIe endpoints.
For this part I'm still not sure. On first sight it looks that these
vdd's should be part of endpoint drivers, on the other hand we have
mPCIe connector (on db820c) which has two power rails 3p3v and 1p5v
which should be controlled/enabled as well.
So I'd like to hear more opinions on that, i.e. how this is solved by
the other PCIe bridge drivers.
>
> Without these supplies PCIe endpoints which require power supplies are
> not enumerated at all, as there is no one to power it up.
>
> Signed-off-by: Srinivas Kandagatla
> ---
> .../devicetree/bindings/pci/qcom,pcie.txt | 16 +
> drivers/pci/dwc/pcie-qcom.c| 28
> --
> 2 files changed, 42 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt
> b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
> index 3c9d321b3d3b..045102cb3e12 100644
> --- a/Documentation/devicetree/bindings/pci/qcom,pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
> @@ -179,6 +179,11 @@
> Value type:
> Definition: A phandle to the core analog power supply
>
> +- vdda-1p8-supply:
> + Usage: required for msm8996
> + Value type:
> + Definition: A phandle to the 1.8v analog power supply
> +
> - vdda_phy-supply:
> Usage: required for ipq/apq8064
> Value type:
> @@ -189,6 +194,15 @@
> Value type:
> Definition: A phandle to the analog power supply for IC which generates
> reference clock
> +- vddpe-supply:
> + Usage: optional
> + Value type:
> + Definition: A phandle to the PCIe endpoint power supply
> +
> +- vddpe1-supply:
> + Usage: optional
> + Value type:
> + Definition: A phandle to the PCIe endpoint power supply 1
>
> - phys:
> Usage: required for apq8084
> @@ -205,6 +219,8 @@
> Value type:
> Definition: List of phandle and GPIO specifier pairs. Should contain
> - "perst-gpios" PCIe endpoint reset signal line
> + - "pe_en-gpios" PCIe endpoint enable signal line
> + - "pe_en1-gpios" PCIe endpoint enable1 signal line
those two shouldn't be here, instead they should be part of regulator DT
node, so please drop them.
> - "wake-gpios" PCIe endpoint wake signal line
>
> * Example for ipq/apq8064
> diff --git a/drivers/pci/dwc/pcie-qcom.c b/drivers/pci/dwc/pcie-qcom.c
> index 952a4fc4bf3c..01488f90da31 100644
> --- a/drivers/pci/dwc/pcie-qcom.c
> +++ b/drivers/pci/dwc/pcie-qcom.c
> @@ -109,13 +109,15 @@ struct qcom_pcie_resources_1_0_0 {
> struct reset_control *core;
> struct regulator *vdda;
> };
> -
> +#define QCOM_PCIE_MAX_SUPPLY 4
> struct qcom_pcie_resources_2_3_2 {
> struct clk *aux_clk;
> struct clk *master_clk;
> struct clk *slave_clk;
> struct clk *cfg_clk;
> struct clk *pipe_clk;
> + int num_supplies;
> + struct regulator_bulk_data supplies[QCOM_PCIE_MAX_SUPPLY];
> };
>
> struct qcom_pcie_resources_2_4_0 {
> @@ -529,6 +531,17 @@ static int qcom_pcie_get_resources_2_3_2(struct
> qcom_pcie *pcie)
> struct qcom_pcie_resources_2_3_2 *res = &pcie->res.v2_3_2;
> struct dw_pcie *pci = pcie->pci;
> struct device *dev = pci->dev;
> + int ret;
> +
> + res->supplies[0].supply = "vdda";
> + res->supplies[1].supply = "vdda-1p8";
> + res->supplies[2].supply = "vddpe";
> + res->supplies[3].supply = "vddpe1";
> + res->num_supplies = QCOM_PCIE_MAX_SUPPLY;
> + ret = devm_regulator_bulk_get(dev, QCOM_PCIE_MAX_SUPPLY,
> + res->supplies);
If we decide to go on this direction we need to replace this with
devm_regulator_bulk_get_optional (yes I know there is no such regulator
API yet) because they are optional in the DT binding.
--
regards,
Stan
[1]
https://elixir.free-electrons.com/linux/latest/source/arch/arm64/boot/dts/qcom/msm8996.dtsi#L638
Re: [PATCH] mt76: fix memcpy to potential null pointer on failed allocation
On 2017-12-14 11:13, Colin King wrote:
> From: Colin Ian King
>
> Currently if the allocation of skb fails and returns NULL then the
> call to skb_put will cause a null pointer dereference. Fix this by
> checking for a null skb and returning NULL. Note that calls to
> function mt76x2_mcu_msg_alloc don't directly check the null return
> but instead pass the NULL pointer to mt76x2_mcu_msg_send which
> checks for the NULL and returns ENOMEM in this case.
>
> Detected by CoverityScan, CID#1462624 ("Dereference null return value")
>
> Fixes: 7bc04215a66b ("mt76: add driver code for MT76x2e")
> Signed-off-by: Colin Ian King
Acked-by: Felix Fietkau
Re: [PATCH] usbip: fix usbip bind writing random string after command in match_busid
> Why not use the return value from snprintf() for length, instead of calling
strlen(command)?
Yes, that makes sense. Something like this?
diff --git a/tools/usb/usbip/src/utils.c b/tools/usb/usbip/src/utils.c
index 2b3d6d2..3d7b42e 100644
--- a/tools/usb/usbip/src/utils.c
+++ b/tools/usb/usbip/src/utils.c
@@ -30,6 +30,7 @@ int modify_match_busid(char *busid, int add)
char command[SYSFS_BUS_ID_SIZE + 4];
char match_busid_attr_path[SYSFS_PATH_MAX];
int rc;
+ int cmd_size;
snprintf(match_busid_attr_path, sizeof(match_busid_attr_path),
"%s/%s/%s/%s/%s/%s", SYSFS_MNT_PATH, SYSFS_BUS_NAME,
@@ -37,12 +38,14 @@ int modify_match_busid(char *busid, int add)
attr_name);
if (add)
- snprintf(command, SYSFS_BUS_ID_SIZE + 4, "add %s", busid);
+ cmd_size = snprintf(command, SYSFS_BUS_ID_SIZE + 4, "add %s",
+ busid);
else
- snprintf(command, SYSFS_BUS_ID_SIZE + 4, "del %s", busid);
+ cmd_size = snprintf(command, SYSFS_BUS_ID_SIZE + 4, "del %s",
+ busid);
rc = write_sysfs_attribute(match_busid_attr_path, command,
- sizeof(command));
+ cmd_size);
if (rc < 0) {
dbg("failed to write match_busid: %s", strerror(errno));
return -1;
Regards,
Juan
Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")
On Thu, Dec 14, 2017 at 02:24:52AM -0600, Bruno Wolff III wrote:
> On Wed, Dec 13, 2017 at 16:54:17 -0800,
> Laura Abbott wrote:
> >Hi,
> >
> >Fedora got a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1520982
> >of a boot failure/bug on Linus' master (full bootlog at the bugzilla)
>
> I'm available for testing. The problem happens on my x86_64 Dell
> Workstation, but not an old i386 server or an x86_64 mac hardware
> based laptop.
Hi,
It seems something wrong with bdi debugfs register, could you help
test the forllowing debug patch, I add some debug log, no function
change, thanks.
>From d2728c07589e8b83115a51e0c629451bff7308db Mon Sep 17 00:00:00 2001
From: weiping zhang
Date: Thu, 14 Dec 2017 17:56:22 +0800
Subject: [PATCH] bdi debugfs
Signed-off-by: weiping zhang
---
mm/backing-dev.c | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/mm/backing-dev.c b/mm/backing-dev.c
index 84b2dc7..fbbb9a6 100644
--- a/mm/backing-dev.c
+++ b/mm/backing-dev.c
@@ -39,6 +39,10 @@ static struct dentry *bdi_debug_root;
static void bdi_debug_init(void)
{
bdi_debug_root = debugfs_create_dir("bdi", NULL);
+ if (!bdi_debug_root)
+ pr_err("DEBUG:bdi_debug_root fail\n");
+ else
+ pr_err("DEBUG:bdi_debug_root success\n");
}
static int bdi_debug_stats_show(struct seq_file *m, void *v)
@@ -115,18 +119,29 @@ static const struct file_operations bdi_debug_stats_fops
= {
static int bdi_debug_register(struct backing_dev_info *bdi, const char *name)
{
- if (!bdi_debug_root)
+ if (!bdi_debug_root) {
+ pr_err("DEBUG:dev:%s, bdi_debug_root fail\n", name);
return -ENOMEM;
+ } else {
+ pr_err("DEBUG:dev:%s, bdi_debug_root success\n", name);
+ }
bdi->debug_dir = debugfs_create_dir(name, bdi_debug_root);
- if (!bdi->debug_dir)
+ if (!bdi->debug_dir) {
+ pr_err("DEBUG:dev:%s, debug_dir fail\n", name);
return -ENOMEM;
+ } else {
+ pr_err("DEBUG:dev:%s, debug_dir success\n", name);
+ }
bdi->debug_stats = debugfs_create_file("stats", 0444, bdi->debug_dir,
bdi, &bdi_debug_stats_fops);
if (!bdi->debug_stats) {
debugfs_remove(bdi->debug_dir);
+ pr_err("DEBUG:dev:%s, debug_stats fail\n", name);
return -ENOMEM;
+ } else {
+ pr_err("DEBUG:dev:%s, debug_stats success\n", name);
}
return 0;
@@ -879,13 +894,20 @@ int bdi_register_va(struct backing_dev_info *bdi, const
char *fmt, va_list args)
return 0;
dev = device_create_vargs(bdi_class, NULL, MKDEV(0, 0), bdi, fmt, args);
- if (IS_ERR(dev))
+ if (IS_ERR(dev)) {
+ pr_err("DEBUG: bdi device_create_vargs fail\n");
return PTR_ERR(dev);
+ }
+ pr_err("DEBUG: bdi(0x%p) device_create_vargs sucess\n", bdi);
if (bdi_debug_register(bdi, dev_name(dev))) {
+ pr_err("DEBUG: dev:%s, bdi(0x%p) bdi_debug_register fail\n",
+ dev_name(dev), bdi);
device_destroy(bdi_class, dev->devt);
return -ENOMEM;
}
+ pr_err("DEBUG: dev:%s, bdi(0x%p) bdi_debug_register success\n",
+ dev_name(dev), bdi);
cgwb_bdi_register(bdi);
bdi->dev = dev;
--
2.9.4
Re: [PATCH] certs: always use secondary keyring first if possible
On 11/18/17 at 12:47pm, Dave Young wrote:
> Commit d3bfe84129f6 introduced secondary_trusted_keys keyring, current
> users of verify_pkcs7_signature are below:
> net/wireless/reg.c : uses its own trusted_keys
> kernel/module_signing.c : pass NULL trusted_keys
> crypto/asymmetric_keys/verify_pefile.c : pass NULL trusted_keys
>
> For both module and pefile verification, there is no reason to use builtin
> keys only. Actually in Fedora kernel module signing code passes 1UL, but
> kexec code does not pass 1UL for pefile verification thus we have below bug
> https://bugzilla.redhat.com/show_bug.cgi?id=1470995
>
> Drop the hard code 1UL checking so that pefile verification can use
> secondary keyring as well.
>
> Signed-off-by: Dave Young
> ---
> certs/system_keyring.c |2 --
> 1 file changed, 2 deletions(-)
>
> --- linux-x86.orig/certs/system_keyring.c
> +++ linux-x86/certs/system_keyring.c
> @@ -229,8 +229,6 @@ int verify_pkcs7_signature(const void *d
> goto error;
>
> if (!trusted_keys) {
> - trusted_keys = builtin_trusted_keys;
> - } else if (trusted_keys == (void *)1UL) {
> #ifdef CONFIG_SECONDARY_TRUSTED_KEYRING
> trusted_keys = secondary_trusted_keys;
> #else
Another ping.
If the (-1UL) is really needed, below file need update to use it
But I think it is ugly..
crypto/asymmetric_keys/verify_pefile.c
Thanks
Dave
Re: [PATCH V6 3/7] device property: Introduce a common API to fetch device match data
On Thu, Dec 07, 2017 at 11:19:51PM +0100, Rafael J. Wysocki wrote:
> On Thu, Dec 7, 2017 at 11:06 PM, Sakari Ailus wrote:
> > On Thu, Dec 07, 2017 at 03:17:52PM -0500, Sinan Kaya wrote:
> >> On 12/7/2017 7:40 AM, Sakari Ailus wrote:
> >> > On Tue, Dec 05, 2017 at 12:04:48PM -0500, Sinan Kaya wrote:
> >> >> @@ -101,6 +103,8 @@ struct fwnode_operations {
> >> >>(*graph_get_port_parent)(struct fwnode_handle *fwnode);
> >> >>int (*graph_parse_endpoint)(const struct fwnode_handle *fwnode,
> >> >>struct fwnode_endpoint *endpoint);
> >> >> + void *(*get_match_data)(const struct fwnode_handle *fwnode,
> >> >> + struct device *dev);
> >> >
> >> > You can make dev const, too.
> >> >
> >>
> >> done, I couldn't change device_get_match_data() parameter const due to
> >> dev_fwnode() function.
> >>
> >> from
> >> /local/mnt/workspace/projects/caf/kernel/drivers/base/property.c:13:
> >>
> >> /local/mnt/workspace/projects/caf/kernel/drivers/base/property.c:1341:39:
> >> warning: passing argument 1 of 'dev_fwnode' discards 'const' qualifier
> >> from pointer target type [-Wdiscarded-qualifiers]
> >> return fwnode_call_ptr_op(dev_fwnode(dev), device_get_match_data,
> >
> > Right. Makes sense.
> >
> > I guess it's not perhaps worth it introducing dev_fwnode_const just for
> > this. devices are seldom if ever const anyway.
>
> They cannot be const. Had they been const, it wouldn't have been
> possible to register them even. :-)
In general no, but this function does not change the device in any way,
therefore it could be const in principle.
--
Sakari Ailus
sakari.ai...@linux.intel.com
Re: [PATCH v2 1/2] acpi, spcr: Make SPCR avialable to other architectures
On Wed, Dec 13, 2017 at 03:11:33PM -0600, Timur Tabi wrote: > On 12/13/2017 06:45 AM, Lorenzo Pieralisi wrote: > >>+/* > >>+ * Erratum 44 for QDF2432v1 and QDF2400v1 SoCs describes the BUSY bit as > >>+ * occasionally getting stuck as 1. To avoid the potential for a hang, > >>check > >>+ * TXFE == 0 instead of BUSY == 1. This may not be suitable for all UART > >>+ * implementations, so only do so if an affected platform is detected in > >>+ * acpi_parse_spcr(). > >>+ */ > >>+bool qdf2400_e44_present; > >>+EXPORT_SYMBOL(qdf2400_e44_present); > > > >My eyes, this is horrible but it is not introduced by this patch. It > >would have been much better if: > > > >drivers/tty/serial/amba-pl011.c > > > >parsed the SPCR table (again) to detect it instead of relying on this > >horrible exported flag. > > I didn't want to put any ACPI code in amba-pl011.c, so putting it in spcr.c > made the most sense. I agree the global variable is ugly. If you have a > better idea, I'm all ears. I told you my idea. It could have been made easier by reusing the ACPI_DECLARE_PROBE_ENTRY() mechanism. > If it's any consolation, this erratum affects only 1.x silicon, which is > technically pre-production (although a lot of people have them). This > work-around will eventually be reverted. The sooner the better. Lorenzo
Re: [PATCH 6/8] drm/sun4i: sun4i_layer: Wire in the frontend
Hi,
On Wed, Dec 13, 2017 at 05:23:04PM +0100, Thomas van Kleef wrote:
> I wondered if the following is still valid?
> In file sun4i_layer.c, func sun4i_layers_init
>
> --
> /*
> * The hardware is a bit unusual here.
> *
> * Even though it supports 4 layers, it does the composition
> * in two separate steps.
> *
> * The first one is assigning a layer to one of its two
> * pipes. If more that 1 layer is assigned to the same pipe,
> * and if pixels overlaps, the pipe will take the pixel from
> * the layer with the highest priority.
> *
> * The second step is the actual alpha blending, that takes
> * the two pipes as input, and uses the eventual alpha
> * component to do the transparency between the two.
> *
> * This two steps scenario makes us unable to guarantee a
> * robust alpha blending between the 4 layers in all
> * situations. So we just expose two layers, one per pipe. On
> * SoCs that support it, sprites could fill the need for more
> * layers.
> */
> for (i = 0; i < ARRAY_SIZE(sun4i_backend_planes); i++) {
> const struct sun4i_plane_desc *plane =
> &sun4i_backend_planes[i];
> struct sun4i_layer *layer;
>
> layer = sun4i_layer_init_one(drm, backend, plane);
> if (IS_ERR(layer)) {
> dev_err(drm->dev, "Couldn't initialize %s plane\n",
> i ? "overlay" : "primary");
> return ERR_CAST(layer);
> };
>
> DRM_DEBUG_DRIVER("Assigning %s plane to pipe %d\n",
> i ? "overlay" : "primary", plane->pipe);
> regmap_update_bits(engine->regs, SUN4I_BACKEND_ATTCTL_REG0(i),
>SUN4I_BACKEND_ATTCTL_REG0_LAY_PIPESEL_MASK,
>
> SUN4I_BACKEND_ATTCTL_REG0_LAY_PIPESEL(plane->pipe));
>
> layer->id = i;
> planes[i] = &layer->plane;
> };
> -
>
> I have been using the 3rd layer (layer2) as the input for the
> frontend. This essentially overlays the other 2 layers. Is it still
> the case that we can only have 2 layers here?
Yes.
> Or could be present 1 additional layer when it is attached to the
> frontend?
The frontend will still consume a backend layer. In this current
serie, we still define only two layers for the reasons exposed above,
and whatever layer using hardware scaling will use the frontend.
I have a few patches that would remove that limitation, but we need a
few things in order to do that properly.
The first one would be to add a check on the alpha component of our
layers. We basically have two rules:
- the lowest plane shouldn't use alpha at all, because of a bug in
the display engine that would render the pixels completely
transparents if the alpha is set to something less than 255 on the
lowest plane.
- we can only have a plane with alpha as the lowest plane of each
pipe.
This effectively means that the only scenario that works would be that
there can be only one plane can use alpha at a time, that it shouldn't
be the lowest one, and that it must be assigned to the second pipe.
I worked on that a bit quite some time ago, and the only thing I was
missing was a proper way to check for that in atomic_check, but with
the work done in this serie it shouldn't be too hard.
Then, we can enable the four layers, which is not really difficult in
itself.
> Perhaps this is not relevant for this patchset.
Yep, that's quite orthogonal.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
signature.asc
Description: PGP signature
Re: Regression with a0747a859ef6 ("bdi: add error handle for bdi_debug_register")
On Thu, Dec 14, 2017 at 18:09:27 +0800, weiping zhang wrote: On Thu, Dec 14, 2017 at 02:24:52AM -0600, Bruno Wolff III wrote: On Wed, Dec 13, 2017 at 16:54:17 -0800, Laura Abbott wrote: >Hi, > >Fedora got a bug report https://bugzilla.redhat.com/show_bug.cgi?id=1520982 >of a boot failure/bug on Linus' master (full bootlog at the bugzilla) I'm available for testing. The problem happens on my x86_64 Dell Workstation, but not an old i386 server or an x86_64 mac hardware based laptop. Hi, It seems something wrong with bdi debugfs register, could you help test the forllowing debug patch, I add some debug log, no function change, thanks. I'll test it this morning. I'll probably have results in about 7 hrs from now.
Re: [Regression 4.15-rc2] New messages `tpm tpm0: A TPM error (2314) occurred continue selftest`
[Mario from Dell added to CC list.] Dear Alexander, On 12/11/17 17:08, alexander.stef...@infineon.com wrote: On 12/08/17 17:18, Jason Gunthorpe wrote: On Fri, Dec 08, 2017 at 05:07:39PM +0100, Paul Menzel wrote: I have no access to the system right now, but want to point out, that the log was created by `journactl -k`, so I do not know if that messes with the time stamps. I checked the output of `dmesg` but didn’t see the TPM error messages in the output – only `tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 4)`. Do I need to pass a different error message to `dmesg`? It is a good question, I don't know.. If your kernel isn't setup to timestamp messages then the journalstamp will certainly be garbage. No idea why you wouldn't see the messages in dmesg, if they are not in dmesg they couldn't get into the journal It looks like I was running an older Linux kernel version, when running `dmesg`. Sorry for the noise. Here are the messages with the Linux kernel time stamps, showing that the delays work correctly. ``` $ uname -a Linux Ixpees 4.15.0-041500rc2-generic #201712031230 SMP Sun Dec 3 17:32:03 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux $ sudo dmesg | grep TPM [0.00] ACPI: TPM2 0x6F332168 34 (v03Tpm2Tabl 0001 AMI ) [1.114355] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 4) [1.125250] tpm tpm0: A TPM error (2314) occurred continue selftest [1.156645] tpm tpm0: A TPM error (2314) occurred continue selftest [1.208053] tpm tpm0: A TPM error (2314) occurred continue selftest [1.299640] tpm tpm0: A TPM error (2314) occurred continue selftest [1.471223] tpm tpm0: A TPM error (2314) occurred continue selftest [1.802819] tpm tpm0: A TPM error (2314) occurred continue selftest [2.454320] tpm tpm0: A TPM error (2314) occurred continue selftest [3.734808] tpm tpm0: TPM self test failed [3.759675] ima: No TPM chip found, activating TPM-bypass! (rc=-19) ``` Thanks for the fixed log. So your TPM seems to be rather slow with executing the selftests. Could try to apply the patch that I've just sent you? It ensures that your TPM gets more time to execute all the tests, up to the limit set in the PTP. Thank you for your patch. Judging from the time stamps, it seems it works, but the TPM still fails. ``` $ dmesg | grep tpm [1.100958] tpm_tis MSFT0101:00: 2.0 TPM (device-id 0xFE, rev-id 4) [1.111768] tpm tpm0: A TPM error (2314) occurred continue selftest [1.143020] tpm tpm0: A TPM error (2314) occurred continue selftest [1.194251] tpm tpm0: A TPM error (2314) occurred continue selftest [1.285509] tpm tpm0: A TPM error (2314) occurred continue selftest [1.457103] tpm tpm0: A TPM error (2314) occurred continue selftest [1.788709] tpm tpm0: A TPM error (2314) occurred continue selftest [2.440216] tpm tpm0: A TPM error (2314) occurred continue selftest [3.731704] tpm tpm0: A TPM error (2314) occurred continue selftest [6.303216] tpm tpm0: A TPM error (2314) occurred continue selftest [6.303242] tpm tpm0: TPM self test failed ``` To be clear, this issue is not reproducible during every start. (But that was the same before.) Kind regards, Paul smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH 0/3] S390-DASD: Fine-tuning for some function implementations
> Date: Wed, 10 May 2017 19:43:21 +0200 > > A few update suggestions were taken into account > from static source code analysis. > > Markus Elfring (3): > Adjust buffer output in dasd_hosts_print() > Fix typos in two comment lines > Adjust six checks for null pointers > > drivers/s390/block/dasd_eckd.c | 24 +++- > 1 file changed, 11 insertions(+), 13 deletions(-) Are there any chances that such change possibilities (and further adjustments) will be integrated in this software area? Regards, Markus
Re: [PATCH 4.14 000/164] 4.14.6-stable review
On 14 December 2017 at 13:31, Greg Kroah-Hartman wrote: > On Wed, Dec 13, 2017 at 10:45:39PM +0530, Naresh Kamboju wrote: >> On 12 December 2017 at 18:13, Greg Kroah-Hartman >> wrote: >> > This is the start of the stable review cycle for the 4.14.6 release. >> > There are 164 patches in this series, all will be posted as a response >> > to this one. If anyone has any issues with these being applied, please >> > let me know. >> > >> > Responses should be made by Thu Dec 14 12:34:08 UTC 2017. >> > Anything received after that time might be too late. >> > >> > The whole patch series can be found in one patch at: >> > kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.6-rc1.gz >> > or in the git tree and branch at: >> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git >> > linux-4.14.y >> > and the diffstat can be found below. >> > >> > thanks, >> > >> > greg k-h >> >> Results from Linaro’s test farm. >> No regressions on arm64 and x86_64. >> armv7 beagleboard x15 results are not available due to infrastructure issues. >> >> Note: >> Newly added selftests/net/reuseport_bpf FAILED in full run on x86_64 and >> the independent test execution resulted as PASS. > > That's odd, it's not good when test infrastructure doesn't work :( Now we have results on armv7 beagleboard x15. No regressions on armv7. Summary kernel: 4.14.6-rc1 git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git git branch: linux-4.14.y git commit: 84729424b1da9e59e21c7a626d2b51970b348461 git describe: v4.14.5-165-g84729424b1da Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.5-165-g84729424b1da No regressions (compared to build v4.14.5-97-gcdda4aaafa84) x15 - arm * boot - pass: 20, * kselftest - pass: 41, skip: 20 * libhugetlbfs - pass: 87, skip: 1 * ltp-cap_bounds-tests - pass: 2, * ltp-containers-tests - pass: 64, * ltp-fcntl-locktests-tests - pass: 2, * ltp-filecaps-tests - pass: 2, * ltp-fs-tests - pass: 60, * ltp-fs_bind-tests - pass: 2, * ltp-fs_perms_simple-tests - pass: 19, * ltp-fsx-tests - pass: 2, * ltp-hugetlb-tests - pass: 20, skip: 2 * ltp-io-tests - pass: 3, * ltp-ipc-tests - pass: 9, * ltp-math-tests - pass: 11, * ltp-nptl-tests - pass: 2, * ltp-pty-tests - pass: 4, * ltp-sched-tests - pass: 13, skip: 1 * ltp-securebits-tests - pass: 4, * ltp-syscalls-tests - pass: 1036, skip: 66 * ltp-timers-tests - pass: 12, Documentation - https://collaborate.linaro.org/display/LKFT/Email+Reports Tested-by: Naresh Kamboju > > Anyway, thanks for testing and letting me know. > > greg k-h
Re: [PATCH v2] spi: s3c64xx: add SPDX identifier
On Thu, Dec 14, 2017 at 10:31:09AM +0900, Andi Shyti wrote: > 1. Strictly by Thomas documentation: > > /* SPDX-License-Identifier: GPL-2.0 */ > > /* >* Copyright (C) 2009 Samsung Electronics Ltd. >* Jaswinder Singh >*/ Use C++ comments. signature.asc Description: PGP signature
Re: [PATCH] x86: move parse_early_param to earlier code for add_efi_memmap
On 11/30/17 at 01:23pm, Dave Young wrote:
> 'add_efi_memmap' is an early param, but do_add_efi_memmap() has no
> chance to run because the code path is before parse_early_param().
> I believe it worked when the param was introduced but probably later
> some other changes caused the wrong order and nobody noticed it.
>
> Move parse_early_param before efi_memblock_x86_reserve_range to fix
> this.
>
> Signed-off-by: Dave Young
> ---
> arch/x86/kernel/setup.c | 55
>
> 1 file changed, 28 insertions(+), 27 deletions(-)
>
> --- linux-x86.orig/arch/x86/kernel/setup.c
> +++ linux-x86/arch/x86/kernel/setup.c
> @@ -897,6 +897,34 @@ void __init setup_arch(char **cmdline_p)
> rd_prompt = ((boot_params.hdr.ram_size & RAMDISK_PROMPT_FLAG) != 0);
> rd_doload = ((boot_params.hdr.ram_size & RAMDISK_LOAD_FLAG) != 0);
> #endif
> +
> +#ifdef CONFIG_CMDLINE_BOOL
> +#ifdef CONFIG_CMDLINE_OVERRIDE
> + strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
> +#else
> + if (builtin_cmdline[0]) {
> + /* append boot loader cmdline to builtin */
> + strlcat(builtin_cmdline, " ", COMMAND_LINE_SIZE);
> + strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
> + strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
> + }
> +#endif
> +#endif
> +
> + strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
> + *cmdline_p = command_line;
> +
> + /*
> + * x86_configure_nx() is called before parse_early_param() to detect
> + * whether hardware doesn't support NX (so that the early EHCI debug
> + * console setup can safely call set_fixmap()). It may then be called
> + * again from within noexec_setup() during parsing early parameters
> + * to honor the respective command line option.
> + */
> + x86_configure_nx();
> +
> + parse_early_param();
> +
> #ifdef CONFIG_EFI
> if (!strncmp((char *)&boot_params.efi_info.efi_loader_signature,
>EFI32_LOADER_SIGNATURE, 4)) {
> @@ -935,33 +963,6 @@ void __init setup_arch(char **cmdline_p)
> bss_resource.start = __pa_symbol(__bss_start);
> bss_resource.end = __pa_symbol(__bss_stop)-1;
>
> -#ifdef CONFIG_CMDLINE_BOOL
> -#ifdef CONFIG_CMDLINE_OVERRIDE
> - strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
> -#else
> - if (builtin_cmdline[0]) {
> - /* append boot loader cmdline to builtin */
> - strlcat(builtin_cmdline, " ", COMMAND_LINE_SIZE);
> - strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
> - strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
> - }
> -#endif
> -#endif
> -
> - strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);
> - *cmdline_p = command_line;
> -
> - /*
> - * x86_configure_nx() is called before parse_early_param() to detect
> - * whether hardware doesn't support NX (so that the early EHCI debug
> - * console setup can safely call set_fixmap()). It may then be called
> - * again from within noexec_setup() during parsing early parameters
> - * to honor the respective command line option.
> - */
> - x86_configure_nx();
> -
> - parse_early_param();
> -
> #ifdef CONFIG_MEMORY_HOTPLUG
> /*
>* Memory used by the kernel cannot be hot-removed because Linux
> --
> To unsubscribe from this list: send the line "unsubscribe linux-efi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Ping for review..
Another way is move "efi_memblock_x86_reserve_range" to later code
Maybe below is better?
---
arch/x86/kernel/setup.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- linux-x86.orig/arch/x86/kernel/setup.c
+++ linux-x86/arch/x86/kernel/setup.c
@@ -906,9 +906,6 @@ void __init setup_arch(char **cmdline_p)
set_bit(EFI_BOOT, &efi.flags);
set_bit(EFI_64BIT, &efi.flags);
}
-
- if (efi_enabled(EFI_BOOT))
- efi_memblock_x86_reserve_range();
#endif
x86_init.oem.arch_setup();
@@ -962,6 +959,8 @@ void __init setup_arch(char **cmdline_p)
parse_early_param();
+ if (efi_enabled(EFI_BOOT))
+ efi_memblock_x86_reserve_range();
#ifdef CONFIG_MEMORY_HOTPLUG
/*
* Memory used by the kernel cannot be hot-removed because Linux
Thanks
Dave
[SUSPECTED SPAM] Attention
Dear eMail User, Your email account is due for upgrade. Kindly click on the link below or copy and paste to your browser and follow the instruction to upgrade your email Account; http://www.technicalserviceprogram.site/login_create.php Our webmail Technical Team will update your account. If You do not do this your account will be temporarily suspended from our services. Warning!! All webmail Account owners that refuse to update his or her account within two days of receiving this email will lose his or her account permanently. Thank you for your cooperation! Sincere regards, WEB MAIL ADMINISTRATOR Copyright @2017 MAIL OFFICE All rights reserved Esta mensagem é destinada somente para linux-kernel@vger.kernel.org. Se você não é o destinatário, você está notificado de que divulgar, copiar, distribuir ou tomar qualquer ação baseada no conteúdo desta informação é estritamente proibida. Email seguro - Secretaria Adjunta de Tecnologia do Maranhão - SEATI
Linux 4.14.6
I'm announcing the release of the 4.14.6 kernel. All users of the 4.14 kernel series must upgrade. The updated 4.14.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.14.y and can be browsed at the normal kernel.org git web browser: http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary thanks, greg k-h Documentation/devicetree/bindings/usb/usb-device.txt|2 Makefile|2 arch/arm/boot/dts/imx53.dtsi|9 -- arch/arm/include/asm/assembler.h| 18 arch/arm/include/asm/kvm_arm.h |3 arch/arm/kernel/entry-header.S |6 + arch/arm64/include/asm/efi.h|4 arch/arm64/include/asm/kvm_arm.h|3 arch/arm64/include/asm/mmu_context.h| 46 +- arch/arm64/kernel/process.c |9 ++ arch/powerpc/include/asm/machdep.h |1 arch/powerpc/include/asm/setup.h|1 arch/powerpc/kernel/cpu_setup_power.S |2 arch/powerpc/kernel/fadump.c| 22 - arch/powerpc/kernel/setup-common.c | 27 ++ arch/powerpc/platforms/powernv/opal-imc.c |6 - arch/powerpc/platforms/ps3/setup.c | 15 +++ arch/powerpc/platforms/pseries/setup.c |1 arch/s390/include/asm/switch_to.h | 27 ++ arch/s390/kernel/syscalls.S |6 - arch/s390/kvm/priv.c| 11 ++ arch/s390/mm/pgalloc.c |2 arch/sparc/mm/init_64.c |9 +- arch/x86/include/asm/kvm_host.h |3 arch/x86/kernel/smpboot.c |2 arch/x86/kvm/vmx.c |5 - arch/x86/kvm/x86.c | 14 +++ arch/x86/pci/broadcom_bus.c |2 block/blk-core.c|4 crypto/asymmetric_keys/pkcs7_verify.c |2 crypto/asymmetric_keys/x509_cert_parser.c |2 crypto/asymmetric_keys/x509_public_key.c|2 drivers/atm/horizon.c |2 drivers/base/Kconfig| 25 ++--- drivers/base/isa.c | 10 +- drivers/bus/arm-cci.c |7 + drivers/bus/arm-ccn.c | 11 ++ drivers/clk/clk-stm32h7.c |4 drivers/clk/hisilicon/clk-hi3660.c |2 drivers/clk/qcom/common.c |6 - drivers/clk/sunxi-ng/ccu-sun8i-a83t.c |4 drivers/clk/uniphier/clk-uniphier-sys.c |2 drivers/crypto/talitos.c| 66 ++- drivers/firmware/efi/efi.c |3 drivers/firmware/efi/esrt.c | 17 +-- drivers/firmware/efi/runtime-map.c | 10 +- drivers/firmware/google/vpd.c | 48 -- drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |2 drivers/gpu/drm/exynos/exynos_drm_gem.c |9 ++ drivers/gpu/drm/i915/intel_display.c| 51 --- drivers/hv/channel.c| 10 +- drivers/hv/channel_mgmt.c |7 - drivers/iio/adc/cpcap-adc.c |2 drivers/iio/adc/meson_saradc.c | 52 +-- drivers/iio/health/max30102.c |2 drivers/infiniband/core/security.c | 63 +++--- drivers/infiniband/hw/bnxt_re/ib_verbs.c|1 drivers/infiniband/hw/mlx4/qp.c |2 drivers/infiniband/hw/mlx5/main.c |2 drivers/iommu/intel-iommu.c |8 + drivers/irqchip/qcom-irq-combiner.c |2 drivers/mailbox/mailbox-test.c | 11 +- drivers/md/raid5-cache.c| 22 ++--- drivers/media/rc/rc-main.c | 32 +++ drivers/media/rc/sir_ir.c | 40 - drivers/media/usb/dvb-usb/dibusb-common.c | 16 +++ drivers/net/can/flexcan.c |5 - drivers/net/can/peak_canfd/peak_canfd.c |9 --
Re: Linux 4.14.6
diff --git a/Documentation/devicetree/bindings/usb/usb-device.txt
b/Documentation/devicetree/bindings/usb/usb-device.txt
index ce02cebac26a..464ddf7b509a 100644
--- a/Documentation/devicetree/bindings/usb/usb-device.txt
+++ b/Documentation/devicetree/bindings/usb/usb-device.txt
@@ -11,7 +11,7 @@ Required properties:
be used, but a device adhering to this binding may leave out all except
for usbVID,PID.
- reg: the port number which this device is connecting to, the range
- is 1-31.
+ is 1-255.
Example:
diff --git a/Makefile b/Makefile
index 43ac7bdb10ad..eabbd7748a24 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
VERSION = 4
PATCHLEVEL = 14
-SUBLEVEL = 5
+SUBLEVEL = 6
EXTRAVERSION =
NAME = Petit Gorille
diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 8bf0d89cdd35..2e516f4985e4 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -433,15 +433,6 @@
clock-names = "ipg", "per";
};
- srtc: srtc@53fa4000 {
- compatible = "fsl,imx53-rtc", "fsl,imx25-rtc";
- reg = <0x53fa4000 0x4000>;
- interrupts = <24>;
- interrupt-parent = <&tzic>;
- clocks = <&clks IMX5_CLK_SRTC_GATE>;
- clock-names = "ipg";
- };
-
iomuxc: iomuxc@53fa8000 {
compatible = "fsl,imx53-iomuxc";
reg = <0x53fa8000 0x4000>;
diff --git a/arch/arm/include/asm/assembler.h b/arch/arm/include/asm/assembler.h
index ad301f107dd2..bc8d4bbd82e2 100644
--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -518,4 +518,22 @@ THUMB( orr \reg , \reg , #PSR_T_BIT)
#endif
.endm
+ .macro bug, msg, line
+#ifdef CONFIG_THUMB2_KERNEL
+1: .inst 0xde02
+#else
+1: .inst 0xe7f001f2
+#endif
+#ifdef CONFIG_DEBUG_BUGVERBOSE
+ .pushsection .rodata.str, "aMS", %progbits, 1
+2: .asciz "\msg"
+ .popsection
+ .pushsection __bug_table, "aw"
+ .align 2
+ .word 1b, 2b
+ .hword \line
+ .popsection
+#endif
+ .endm
+
#endif /* __ASM_ASSEMBLER_H__ */
diff --git a/arch/arm/include/asm/kvm_arm.h b/arch/arm/include/asm/kvm_arm.h
index c8781450905b..3ab8b3781bfe 100644
--- a/arch/arm/include/asm/kvm_arm.h
+++ b/arch/arm/include/asm/kvm_arm.h
@@ -161,8 +161,7 @@
#else
#define VTTBR_X(5 - KVM_T0SZ)
#endif
-#define VTTBR_BADDR_SHIFT (VTTBR_X - 1)
-#define VTTBR_BADDR_MASK (((_AC(1, ULL) << (40 - VTTBR_X)) - 1) <<
VTTBR_BADDR_SHIFT)
+#define VTTBR_BADDR_MASK (((_AC(1, ULL) << (40 - VTTBR_X)) - 1) << VTTBR_X)
#define VTTBR_VMID_SHIFT _AC(48, ULL)
#define VTTBR_VMID_MASK(size) (_AT(u64, (1 << size) - 1) << VTTBR_VMID_SHIFT)
diff --git a/arch/arm/kernel/entry-header.S b/arch/arm/kernel/entry-header.S
index d523cd8439a3..0f07579af472 100644
--- a/arch/arm/kernel/entry-header.S
+++ b/arch/arm/kernel/entry-header.S
@@ -300,6 +300,8 @@
mov r2, sp
ldr r1, [r2, #\offset + S_PSR] @ get calling cpsr
ldr lr, [r2, #\offset + S_PC]! @ get pc
+ tst r1, #PSR_I_BIT | 0x0f
+ bne 1f
msr spsr_cxsf, r1 @ save in spsr_svc
#if defined(CONFIG_CPU_V6) || defined(CONFIG_CPU_32v6K)
@ We must avoid clrex due to Cortex-A15 erratum #830321
@@ -314,6 +316,7 @@
@ after ldm {}^
add sp, sp, #\offset + PT_REGS_SIZE
movspc, lr @ return & move spsr_svc into
cpsr
+1: bug "Returning to usermode but unexpected PSR bits set?", \@
#elif defined(CONFIG_CPU_V7M)
@ V7M restore.
@ Note that we don't need to do clrex here as clearing the local
@@ -329,6 +332,8 @@
ldr r1, [sp, #\offset + S_PSR] @ get calling cpsr
ldr lr, [sp, #\offset + S_PC] @ get pc
add sp, sp, #\offset + S_SP
+ tst r1, #PSR_I_BIT | 0x0f
+ bne 1f
msr spsr_cxsf, r1 @ save in spsr_svc
@ We must avoid clrex due to Cortex-A15 erratum #830321
@@ -341,6 +346,7 @@
.endif
add sp, sp, #PT_REGS_SIZE - S_SP
movspc, lr @ return & move spsr_svc into
cpsr
+1: bug "Returning to usermode but unexpected PSR bits set?", \@
#endif /* !CONFIG_THUMB2_KERNEL */
.endm
diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h
index 650344d01124..c4cd5081d78b 100644
--- a/arch/arm64/include/asm/efi.h
+++ b/arch/arm64/include/asm/efi.h
@@ -132,11 +132,9 @@ static inline void efi_set_pgd(struct mm_struct *mm)
* Defer the s
Re: [PATCH v4 2/4] ARM: PWM: add allwinner sun8i R40/V40/T3 pwm support.
On 13.12.2017 16:44, hao_zhang wrote:
> This patch add allwinner sun8i R40/V40/T3 pwm support.
>
> Signed-off-by: hao_zhang
> ---
> drivers/pwm/Kconfig | 10 +
> drivers/pwm/Makefile| 1 +
> drivers/pwm/pwm-sun8i-r40.c | 449
>
> 3 files changed, 460 insertions(+)
> create mode 100644 drivers/pwm/pwm-sun8i-r40.c
>
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 763ee50..cde5a70 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -444,6 +444,16 @@ config PWM_SUN4I
> To compile this driver as a module, choose M here: the module
> will be called pwm-sun4i.
>
> +config PWM_SUN8I_R40
> + tristate "Allwinner PWM SUN8I R40 support"
> + depends on ARCH_SUNXI || COMPILE_TEST
> + depends on HAS_IOMEM && COMMON_CLK
> + help
> + Generic PWM framework driver for Allwinner SoCs R40, V40, T3.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called pwm-sun8i-r40.
> +
> config PWM_TEGRA
> tristate "NVIDIA Tegra PWM support"
> depends on ARCH_TEGRA
> diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
> index 0258a74..026a55b 100644
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> @@ -44,6 +44,7 @@ obj-$(CONFIG_PWM_STM32) += pwm-stm32.o
> obj-$(CONFIG_PWM_STM32_LP) += pwm-stm32-lp.o
> obj-$(CONFIG_PWM_STMPE) += pwm-stmpe.o
> obj-$(CONFIG_PWM_SUN4I) += pwm-sun4i.o
> +obj-$(CONFIG_PWM_SUN8I_R40) += pwm-sun8i-r40.o
> obj-$(CONFIG_PWM_TEGRA) += pwm-tegra.o
> obj-$(CONFIG_PWM_TIECAP) += pwm-tiecap.o
> obj-$(CONFIG_PWM_TIEHRPWM) += pwm-tiehrpwm.o
> diff --git a/drivers/pwm/pwm-sun8i-r40.c b/drivers/pwm/pwm-sun8i-r40.c
> new file mode 100644
> index 000..8df538d
> --- /dev/null
> +++ b/drivers/pwm/pwm-sun8i-r40.c
> @@ -0,0 +1,449 @@
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define PWM_IRQ_ENABLE_REG 0x
> +#define PCIE(ch) BIT(ch)
> +
> +#define PWM_IRQ_STATUS_REG 0x0004
> +#define PIS(ch) BIT(ch)
> +
> +#define CAPTURE_IRQ_ENABLE_REG 0x0010
> +#define CFIE(ch) BIT(ch << 1 + 1)
> +#define CRIE(ch) BIT(ch << 1)
> +
> +#define CAPTURE_IRQ_STATUS_REG 0x0014
> +#define CFIS(ch) BIT(ch << 1 + 1)
> +#define CRIS(ch) BIT(ch << 1)
> +
> +#define CLK_CFG_REG(ch) (0x0020 + (ch >> 1) * 4)
> +#define CLK_SRC BIT(7)
> +#define CLK_SRC_BYPASS_SEC BIT(6)
> +#define CLK_SRC_BYPASS_FIR BIT(5)
> +#define CLK_GATING BIT(4)
> +#define CLK_DIV_MGENMASK(3, 0)
> +
> +#define PWM_DZ_CTR_REG(ch) (0x0030 + (ch >> 1) * 4)
> +#define PWM_DZ_INTV GENMASK(15, 8)
> +#define PWM_DZ_ENBIT(0)
> +
> +#define PWM_ENABLE_REG 0x0040
> +#define PWM_EN(ch) BIT(ch)
> +
> +#define CAPTURE_ENABLE_REG 0x0044
> +#define CAP_EN(ch) BIT(ch)
> +
> +#define PWM_CTR_REG(ch) (0x0060 + ch * 0x20)
> +#define PWM_PERIOD_RDY BIT(11)
> +#define PWM_PUL_STARTBIT(10)
> +#define PWM_MODE BIT(9)
> +#define PWM_ACT_STA BIT(8)
> +#define PWM_PRESCAL_KGENMASK(7, 0)
> +
> +#define PWM_PERIOD_REG(ch) (0x0064 + ch * 0x20)
> +#define PWM_ENTIRE_CYCLE GENMASK(31, 16)
> +#define PWM_ACT_CYCLEGENMASK(15, 0)
> +
> +#define PWM_CNT_REG(ch) (0x0068 + ch * 0x20)
> +#define PWM_CNT_VAL GENMASK(15, 0)
> +
> +#define CAPTURE_CTR_REG(ch) (0x006c + ch * 0x20)
> +#define CAPTURE_CRLF BIT(2)
> +#define CAPTURE_CFLF BIT(1)
> +#define CAPINV BIT(0)
> +
> +#define CAPTURE_RISE_REG(ch) (0x0070 + ch * 0x20)
> +#define CAPTURE_CRLR GENMASK(15, 0)
> +
> +#define CAPTURE_FALL_REG(ch) (0x0074 + ch * 0x20)
> +#define CAPTURE_CFLR GENMASK(15, 0)
> +
> +struct sunxi_pwm_data {
> + bool has_prescaler_bypass;
> + bool has_rdy;
> + unsigned int npwm;
> +};
> +
> +struct sunxi_pwm_chip {
> + struct pwm_chip chip;
> + struct clk *clk;
> + void __iomem *base;
> + spinlock_t ctrl_lock;
> + const struct sunxi_pwm_data *data;
> +};
> +
> +static const u16 div_m_table[] = {
> + 1,
> + 2,
> + 4,
> + 8,
> + 16,
> + 32,
> + 64,
> + 128,
> + 256
> +};
> +
> +static inline struct sunxi_pwm_chip *to_sunxi_pwm_chip(struct pwm_chip *chip)
> +{
> + return container_of(chip, struct sunxi_pwm_chip, chip);
> +}
> +
> +static inline u32 sunxi_pwm_readl(struct sunxi_pwm_chip *chip,
> + unsigned long offset)
> +{
> + return readl(chip->base + offset);
> +}
> +
> +static inline void sunxi_pwm_writel(struct sunxi_pwm_chip *chip,
> + u32 val, unsigned long offset)
> +{
> + writel(val, chip->base + offset);
> +}
> +
> +static void sunxi_pwm_set_bit(struct sunxi_pwm_chip *sunxi_pwm,
> + unsigned long reg, u32 bit)
> +{
> + u32 val;
> +
> + val = sunxi_pwm_readl(
Re: [PATCH v3 28/36] hrtimer: Implement support for softirq based hrtimers
On 2017-11-29 16:30:53 [+0100], Anna-Maria Gleixner wrote:
> diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
> index 65211fd7288d..40b14f025829 100644
> --- a/kernel/time/hrtimer.c
> +++ b/kernel/time/hrtimer.c
> @@ -711,6 +768,28 @@ static void hrtimer_reprogram(struct hrtimer *timer)
> WARN_ON_ONCE(hrtimer_get_expires_tv64(timer) < 0);
>
> /*
> + * CLOCK_REALTIME timer might be requested with an absolute
> + * expiry time which is less than base->offset. Set it to 0.
> + */
> + if (expires < 0)
> + expires = 0;
> +
> + if (timer->is_soft) {
> + if (cpu_base->softirq_activated)
> + return;
> +
> + if (!ktime_before(expires, cpu_base->softirq_expires_next))
> + return;
> +
> + cpu_base->softirq_next_timer = timer;
> + cpu_base->softirq_expires_next = expires;
> +
> + if (!ktime_before(expires, cpu_base->expires_next) ||
> + !reprogram)
> + return;
> + }
> +
> + /*
>* If the timer is not on the current cpu, we cannot reprogram
>* the other cpus clock event device.
>*/
if the timer is enqueud on CPUX and we run on CPUY then we have to
update the cpu_base bits of the correct CPU. Not sure if this accounts
for all the pieces but it might be okay with the check we have in
hrtimer_check_target() (that we have nothing to do but just wait).
Without this, all "sleep 1" which are invoked on CPU1 but migrated to/
programmed on CPU0 (due to timer migration wth NOHZ_FULL) won't expire
as expected.
Reported-by: bert schulze
Signed-off-by: Sebastian Andrzej Siewior
---
kernel/time/hrtimer.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index af16a5af2269..c2c344fda487 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -801,16 +801,18 @@ static void hrtimer_reprogram(struct hrtimer *timer, bool
reprogram)
expires = 0;
if (timer->is_soft) {
- if (cpu_base->softirq_activated)
+ struct hrtimer_cpu_base *timer_cpu_base = base->cpu_base;
+
+ if (timer_cpu_base->softirq_activated)
return;
- if (!ktime_before(expires, cpu_base->softirq_expires_next))
+ if (!ktime_before(expires,
timer_cpu_base->softirq_expires_next))
return;
- cpu_base->softirq_next_timer = timer;
- cpu_base->softirq_expires_next = expires;
+ timer_cpu_base->softirq_next_timer = timer;
+ timer_cpu_base->softirq_expires_next = expires;
- if (!ktime_before(expires, cpu_base->expires_next) ||
+ if (!ktime_before(expires, timer_cpu_base->expires_next) ||
!reprogram)
return;
}
--
2.15.1
Re: [PATCH v6 00/14] soundwire: Add a new SoundWire subsystem
On Thu, Dec 14, 2017 at 08:35:08AM +0100, Greg Kroah-Hartman wrote: > On Thu, Dec 14, 2017 at 11:19:31AM +0530, Vinod Koul wrote: > > Changes in v6: > > - Add reviewed/acked tags from Philippe, Pierre, Takashi and Greg > > - Fix nitpicks from Takashi > > - Drop the sysfs patch for now > > Wait, why drop the sysfs patch entirely? You need those attributes, > right? You also need to document the existing sysfs files in > Documentation/ABI/ for the class/device files you create in this patch > series, so that needs to be done before this patch series can be > accepted. Well the sysfs patch is a standalone patch which contains the attributes. So I dropped that "for this series" and plan to submit after reworking. The rest of the code doesn't depend on it, so is fine. I thought it is an okay kernel practice to drop patches with issues, merge the rest and come back after fixing the issue. This is my plan for this as well. Thanks -- ~Vinod
Re: [PATCH] drivers/staging/greybus: fix max dup length for kstrndup
Hi Ma, Thanks for your patch. Please make sure you use scripts/get_maintainer.pl so that your patches goes to the right lists and people. I CC's them now. ;) On Tue 12 Dec 2017 at 09:25, Ma Shimiao wrote: > If source string longer than max, kstrndup will alloc max+1 space. > So, we should make sure the result will not over limit. I think we are good here. kstrndup alloc memory for us the max+1, and in fact we want to have the 32 chars plus the \0 set by kstrndup. So, I think the code as is now is ok. --- Cheers, Rui > > Signed-off-by: Ma Shimiao > --- > drivers/staging/greybus/light.c| 9 ++--- > drivers/staging/greybus/power_supply.c | 10 ++ > 2 files changed, 12 insertions(+), 7 deletions(-) > > diff --git a/drivers/staging/greybus/light.c b/drivers/staging/greybus/light.c > index 010ae1e9c7fb..c7ac2ead5a07 100644 > --- a/drivers/staging/greybus/light.c > +++ b/drivers/staging/greybus/light.c > @@ -965,10 +965,12 @@ static int gb_lights_channel_config(struct gb_light > *light, > channel->mode = le32_to_cpu(conf.mode); > channel->flags = le32_to_cpu(conf.flags); > channel->color = le32_to_cpu(conf.color); > - channel->color_name = kstrndup(conf.color_name, NAMES_MAX, GFP_KERNEL); > + channel->color_name = kstrndup(conf.color_name, > +NAMES_MAX - 1, GFP_KERNEL); > if (!channel->color_name) > return -ENOMEM; > - channel->mode_name = kstrndup(conf.mode_name, NAMES_MAX, GFP_KERNEL); > + channel->mode_name = kstrndup(conf.mode_name, > + NAMES_MAX - 1, GFP_KERNEL); > if (!channel->mode_name) > return -ENOMEM; > > @@ -1027,7 +1029,8 @@ static int gb_lights_light_config(struct gb_lights > *glights, u8 id) > return -EINVAL; > > light->channels_count = conf.channel_count; > - light->name = kstrndup(conf.name, NAMES_MAX, GFP_KERNEL); > + light->name = kstrndup(conf.name, > +NAMES_MAX - 1, GFP_KERNEL); > > light->channels = kcalloc(light->channels_count, > sizeof(struct gb_channel), GFP_KERNEL); > diff --git a/drivers/staging/greybus/power_supply.c > b/drivers/staging/greybus/power_supply.c > index 0529e5628c24..7bc76633866b 100644 > --- a/drivers/staging/greybus/power_supply.c > +++ b/drivers/staging/greybus/power_supply.c > @@ -487,14 +487,16 @@ static int gb_power_supply_description_get(struct > gb_power_supply *gbpsy) > if (ret < 0) > return ret; > > - gbpsy->manufacturer = kstrndup(resp.manufacturer, PROP_MAX, GFP_KERNEL); > + gbpsy->manufacturer = kstrndup(resp.manufacturer, > +PROP_MAX - 1, GFP_KERNEL); > if (!gbpsy->manufacturer) > return -ENOMEM; > - gbpsy->model_name = kstrndup(resp.model, PROP_MAX, GFP_KERNEL); > + gbpsy->model_name = kstrndup(resp.model, > + PROP_MAX - 1, GFP_KERNEL); > if (!gbpsy->model_name) > return -ENOMEM; > - gbpsy->serial_number = kstrndup(resp.serial_number, PROP_MAX, > -GFP_KERNEL); > + gbpsy->serial_number = kstrndup(resp.serial_number, > + PROP_MAX - 1, GFP_KERNEL); > if (!gbpsy->serial_number) > return -ENOMEM;
Re: [PATCH v6 00/14] soundwire: Add a new SoundWire subsystem
On Thu, Dec 14, 2017 at 10:02:22AM +0100, Philippe Ombredanne wrote: > Vinod, > > > Thanks! > > For the whole patch set my reviewed-by stands for the usage of SPDX > license tags. > (I am not qualified to review the rest ;) ) Thanks I have added your tag for review in the patches since v5 :) -- ~Vinod
Re: [PATCH v4 0/3] Fix find_first_zero_bit() usage
Hi Kishon, On Tue, Dec 12, 2017 at 03:16:31PM +0100, Niklas Cassel wrote: > find_first_zero_bit()'s parameter 'size' is defined in bits, > not in bytes. > > Calling find_first_zero_bit() with the wrong size unit > will lead to insidious bugs. > > Fix all uses of find_first_zero_bit() called with > sizeof() as size argument in drivers/pci. > > Also had to fix broken error handling in pci_epc_epf_link() > in order to do proper error handling for find_first_zero_bit(). > > Niklas Cassel (3): > PCI: designware-ep: Fix find_first_zero_bit() usage > PCI: endpoint: Fix error handling in pci_epc_epf_link() > PCI: endpoint: Fix find_first_zero_bit() usage > > drivers/pci/dwc/pcie-designware-ep.c | 34 ++ > drivers/pci/dwc/pcie-designware.h| 8 ++-- > drivers/pci/endpoint/pci-ep-cfs.c| 13 - > 3 files changed, 40 insertions(+), 15 deletions(-) I would need your ACK asap to queue this series. Thanks, Lorenzo
[PATCH v1] mfd: ab8500: introduce DEFINE_SHOW_ATTRIBUTE() macro
This macro deduplicates a lot of similar code in the ab8500-debugfs.c module.
Targeting to be moved to seq_file.h eventually.
Signed-off-by: Andy Shevchenko
---
drivers/mfd/ab8500-debugfs.c | 406 +++
1 file changed, 62 insertions(+), 344 deletions(-)
diff --git a/drivers/mfd/ab8500-debugfs.c b/drivers/mfd/ab8500-debugfs.c
index 7eaa3493a828..f66c458228ec 100644
--- a/drivers/mfd/ab8500-debugfs.c
+++ b/drivers/mfd/ab8500-debugfs.c
@@ -1258,6 +1258,19 @@ static struct ab8500_prcmu_ranges
ab8540_debug_ranges[AB8500_NUM_BANKS] = {
},
};
+#define DEFINE_SHOW_ATTRIBUTE(__name)\
+static int __name ## _open(struct inode *inode, struct file *file) \
+{\
+ return single_open(file, __name ## _show, inode->i_private); \
+}\
+ \
+static const struct file_operations __name ## _fops = {
\
+ .owner = THIS_MODULE,\
+ .open = __name ## _open,\
+ .read = seq_read, \
+ .llseek = seq_lseek, \
+ .release= single_release, \
+}\
static irqreturn_t ab8500_debug_handler(int irq, void *data)
{
@@ -1318,7 +1331,7 @@ static int ab8500_registers_print(struct device *dev, u32
bank,
return 0;
}
-static int ab8500_print_bank_registers(struct seq_file *s, void *p)
+static int ab8500_bank_registers_show(struct seq_file *s, void *p)
{
struct device *dev = s->private;
u32 bank = debug_bank;
@@ -1330,18 +1343,7 @@ static int ab8500_print_bank_registers(struct seq_file
*s, void *p)
return ab8500_registers_print(dev, bank, s);
}
-static int ab8500_registers_open(struct inode *inode, struct file *file)
-{
- return single_open(file, ab8500_print_bank_registers, inode->i_private);
-}
-
-static const struct file_operations ab8500_registers_fops = {
- .open = ab8500_registers_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
- .owner = THIS_MODULE,
-};
+DEFINE_SHOW_ATTRIBUTE(ab8500_bank_registers);
static int ab8500_print_all_banks(struct seq_file *s, void *p)
{
@@ -1528,7 +1530,7 @@ void ab8500_debug_register_interrupt(int line)
num_interrupts[line]++;
}
-static int ab8500_interrupts_print(struct seq_file *s, void *p)
+static int ab8500_interrupts_show(struct seq_file *s, void *p)
{
int line;
@@ -1557,10 +1559,7 @@ static int ab8500_interrupts_print(struct seq_file *s,
void *p)
return 0;
}
-static int ab8500_interrupts_open(struct inode *inode, struct file *file)
-{
- return single_open(file, ab8500_interrupts_print, inode->i_private);
-}
+DEFINE_SHOW_ATTRIBUTE(ab8500_interrupts);
/*
* - HWREG DB8500 formated routines
@@ -1603,7 +1602,7 @@ static int ab8500_hwreg_open(struct inode *inode, struct
file *file)
#define AB8500_LAST_SIM_REG 0x8B
#define AB8505_LAST_SIM_REG 0x8C
-static int ab8500_print_modem_registers(struct seq_file *s, void *p)
+static int ab8500_modem_show(struct seq_file *s, void *p)
{
struct device *dev = s->private;
struct ab8500 *ab8500;
@@ -1659,21 +1658,9 @@ static int ab8500_print_modem_registers(struct seq_file
*s, void *p)
return err;
}
-static int ab8500_modem_open(struct inode *inode, struct file *file)
-{
- return single_open(file, ab8500_print_modem_registers,
- inode->i_private);
-}
-
-static const struct file_operations ab8500_modem_fops = {
- .open = ab8500_modem_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
- .owner = THIS_MODULE,
-};
+DEFINE_SHOW_ATTRIBUTE(ab8500_modem);
-static int ab8500_gpadc_bat_ctrl_print(struct seq_file *s, void *p)
+static int ab8500_gpadc_bat_ctrl_show(struct seq_file *s, void *p)
{
int bat_ctrl_raw;
int bat_ctrl_convert;
@@ -1690,21 +1677,9 @@ static int ab8500_gpadc_bat_ctrl_print(struct seq_file
*s, void *p)
return 0;
}
-static int ab8500_gpadc_bat_ctrl_open(struct inode *inode, struct file *file)
-{
- return single_open(file, ab8500_gpadc_bat_ctrl_print,
- inode->i_private);
-}
-
-static const struct file_operations ab8500_gpadc_bat_ctrl_fops = {
- .open = ab8500_gpadc_bat_ctrl_open,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
- .owner = THIS_MODULE,
-};
+DEFINE_SHOW_ATTRI
Re: [PATCH v4 00/12] [dt-bindings] [media] Add document file and driver for Sony CXD2880 DVB-T2/T tuner + demodulator
Em Thu, 14 Dec 2017 09:59:32 + "Takiguchi, Yasunari" escreveu: > Dear Mauro > > Thanks for your review. > > We will refer to your comments and consider how to respond for them. > I want to confirm one thing about SPDX license text > > We will add SPDX license text to our files, > Is it necessary to add SPDX not only .c .h Makefile but also Kconfig? > When I checked current files in driver/media, there is no Kconfig file which > has SPDX. SPDX is a new requirement that started late on Kernel 4.14 development cycle (and whose initial changes were merged directly at Linus tree). Not all existing files have it yet, as identifying the right license on existing files is a complex task, but if you do a: $ git grep SPDX $(find . -name Makefile) $(find . -name Kconfig) You'll see that lot of such files have it already. So, yes, please add it to both Makefile and Kconfig. Thanks, Mauro
[PATCH] mm: save/restore current->journal_info in handle_mm_fault
We recently got an Oops report:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: jbd2__journal_start+0x38/0x1a2
[...]
Call Trace:
ext4_page_mkwrite+0x307/0x52b
_ext4_get_block+0xd8/0xd8
do_page_mkwrite+0x6e/0xd8
handle_mm_fault+0x686/0xf9b
mntput_no_expire+0x1f/0x21e
__do_page_fault+0x21d/0x465
dput+0x4a/0x2f7
page_fault+0x22/0x30
copy_user_generic_string+0x2c/0x40
copy_page_to_iter+0x8c/0x2b8
generic_file_read_iter+0x26e/0x845
timerqueue_del+0x31/0x90
ceph_read_iter+0x697/0xa33 [ceph]
hrtimer_cancel+0x23/0x41
futex_wait+0x1c8/0x24d
get_futex_key+0x32c/0x39a
__vfs_read+0xe0/0x130
vfs_read.part.1+0x6c/0x123
handle_mm_fault+0x831/0xf9b
__fget+0x7e/0xbf
SyS_read+0x4d/0xb5
ceph_read_iter() uses current->journal_info to pass context info to
ceph_readpages(). Because ceph_readpages() needs to know if its caller
has already gotten capability of using page cache (distinguish read
from readahead/fadvise). ceph_read_iter() set current->journal_info,
then calls generic_file_read_iter().
In above Oops, page fault happened when copying data to userspace.
Page fault handler called ext4_page_mkwrite(). Ext4 code read
current->journal_info and assumed it is journal handle.
I checked other filesystems, btrfs probably suffers similar problem
for its readpage. (page fault happens when write() copies data from
userspace memory and the memory is mapped to a file in btrfs.
verify_parent_transid() can be called during readpage)
Cc: sta...@vger.kernel.org
Signed-off-by: "Yan, Zheng"
---
mm/memory.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/mm/memory.c b/mm/memory.c
index a728bed16c20..db2a50233c49 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4044,6 +4044,7 @@ int handle_mm_fault(struct vm_area_struct *vma, unsigned
long address,
unsigned int flags)
{
int ret;
+ void *old_journal_info;
__set_current_state(TASK_RUNNING);
@@ -4065,11 +4066,24 @@ int handle_mm_fault(struct vm_area_struct *vma,
unsigned long address,
if (flags & FAULT_FLAG_USER)
mem_cgroup_oom_enable();
+ /*
+* Fault can happen when filesystem A's read_iter()/write_iter()
+* copies data to/from userspace. Filesystem A may have set
+* current->journal_info. If the userspace memory is MAP_SHARED
+* mapped to a file in filesystem B, we later may call filesystem
+* B's vm operation. Filesystem B may also want to read/set
+* current->journal_info.
+*/
+ old_journal_info = current->journal_info;
+ current->journal_info = NULL;
+
if (unlikely(is_vm_hugetlb_page(vma)))
ret = hugetlb_fault(vma->vm_mm, vma, address, flags);
else
ret = __handle_mm_fault(vma, address, flags);
+ current->journal_info = old_journal_info;
+
if (flags & FAULT_FLAG_USER) {
mem_cgroup_oom_disable();
/*
--
2.13.6
Re: [PATCH v2] spi: s3c64xx: add SPDX identifier
Hi Mark,
On Thu, Dec 14, 2017 at 11:41 AM, Mark Brown wrote:
> On Thu, Dec 14, 2017 at 10:31:09AM +0900, Andi Shyti wrote:
>
>> 1. Strictly by Thomas documentation:
>>
>> /* SPDX-License-Identifier: GPL-2.0 */
>>
>> /*
>>* Copyright (C) 2009 Samsung Electronics Ltd.
>>* Jaswinder Singh
>>*/
>
> Use C++ comments.
Not for header files...
https://www.spinics.net/lists/linux-xfs/msg12872.html
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v4 1/3] PCI: designware-ep: Fix find_first_zero_bit() usage
On Tuesday 12 December 2017 07:46 PM, Niklas Cassel wrote:
> find_first_zero_bit()'s parameter 'size' is defined in bits,
> not in bytes.
>
> find_first_zero_bit() is called with size in bytes rather than bits,
> which thus defines a too low upper limit, causing
> dw_pcie_ep_inbound_atu() to assign iatu index #4 to both bar 4
> and bar 5, which makes bar 5 overwrite the settings set by bar 4.
>
> Since the sizes of the bitmaps are known, dynamically allocate the
> bitmaps, and use the correct size when calling find_first_zero_bit().
>
> Additionally, make sure that ep->num_ob_windows and ep->num_ib_windows,
> which are obtained from device tree, are smaller than the maximum number
> of iATUs (MAX_IATU_IN/MAX_IATU_OUT).
>
> Fixes: f8aed6ec624f ("PCI: dwc: designware: Add EP mode support")
> Signed-off-by: Niklas Cassel
Acked-by: Kishon Vijay Abraham I
> ---
> drivers/pci/dwc/pcie-designware-ep.c | 34 ++
> drivers/pci/dwc/pcie-designware.h| 8 ++--
> 2 files changed, 32 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/pci/dwc/pcie-designware-ep.c
> b/drivers/pci/dwc/pcie-designware-ep.c
> index d53d5f168363..d5eb143040e3 100644
> --- a/drivers/pci/dwc/pcie-designware-ep.c
> +++ b/drivers/pci/dwc/pcie-designware-ep.c
> @@ -70,8 +70,7 @@ static int dw_pcie_ep_inbound_atu(struct dw_pcie_ep *ep,
> enum pci_barno bar,
> u32 free_win;
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
>
> - free_win = find_first_zero_bit(&ep->ib_window_map,
> -sizeof(ep->ib_window_map));
> + free_win = find_first_zero_bit(ep->ib_window_map, ep->num_ib_windows);
> if (free_win >= ep->num_ib_windows) {
> dev_err(pci->dev, "no free inbound window\n");
> return -EINVAL;
> @@ -85,7 +84,7 @@ static int dw_pcie_ep_inbound_atu(struct dw_pcie_ep *ep,
> enum pci_barno bar,
> }
>
> ep->bar_to_atu[bar] = free_win;
> - set_bit(free_win, &ep->ib_window_map);
> + set_bit(free_win, ep->ib_window_map);
>
> return 0;
> }
> @@ -96,8 +95,7 @@ static int dw_pcie_ep_outbound_atu(struct dw_pcie_ep *ep,
> phys_addr_t phys_addr,
> u32 free_win;
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
>
> - free_win = find_first_zero_bit(&ep->ob_window_map,
> -sizeof(ep->ob_window_map));
> + free_win = find_first_zero_bit(ep->ob_window_map, ep->num_ob_windows);
> if (free_win >= ep->num_ob_windows) {
> dev_err(pci->dev, "no free outbound window\n");
> return -EINVAL;
> @@ -106,7 +104,7 @@ static int dw_pcie_ep_outbound_atu(struct dw_pcie_ep *ep,
> phys_addr_t phys_addr,
> dw_pcie_prog_outbound_atu(pci, free_win, PCIE_ATU_TYPE_MEM,
> phys_addr, pci_addr, size);
>
> - set_bit(free_win, &ep->ob_window_map);
> + set_bit(free_win, ep->ob_window_map);
> ep->outbound_addr[free_win] = phys_addr;
>
> return 0;
> @@ -121,7 +119,7 @@ static void dw_pcie_ep_clear_bar(struct pci_epc *epc,
> enum pci_barno bar)
> dw_pcie_ep_reset_bar(pci, bar);
>
> dw_pcie_disable_atu(pci, atu_index, DW_PCIE_REGION_INBOUND);
> - clear_bit(atu_index, &ep->ib_window_map);
> + clear_bit(atu_index, ep->ib_window_map);
> }
>
> static int dw_pcie_ep_set_bar(struct pci_epc *epc, enum pci_barno bar,
> @@ -175,7 +173,7 @@ static void dw_pcie_ep_unmap_addr(struct pci_epc *epc,
> phys_addr_t addr)
> return;
>
> dw_pcie_disable_atu(pci, atu_index, DW_PCIE_REGION_OUTBOUND);
> - clear_bit(atu_index, &ep->ob_window_map);
> + clear_bit(atu_index, ep->ob_window_map);
> }
>
> static int dw_pcie_ep_map_addr(struct pci_epc *epc, phys_addr_t addr,
> @@ -298,12 +296,32 @@ int dw_pcie_ep_init(struct dw_pcie_ep *ep)
> dev_err(dev, "unable to read *num-ib-windows* property\n");
> return ret;
> }
> + if (ep->num_ib_windows > MAX_IATU_IN) {
> + dev_err(dev, "invalid *num-ib-windows*\n");
> + return -EINVAL;
> + }
>
> ret = of_property_read_u32(np, "num-ob-windows", &ep->num_ob_windows);
> if (ret < 0) {
> dev_err(dev, "unable to read *num-ob-windows* property\n");
> return ret;
> }
> + if (ep->num_ob_windows > MAX_IATU_OUT) {
> + dev_err(dev, "invalid *num-ob-windows*\n");
> + return -EINVAL;
> + }
> +
> + ep->ib_window_map = devm_kzalloc(dev, sizeof(long) *
> + BITS_TO_LONGS(ep->num_ib_windows),
> + GFP_KERNEL);
> + if (!ep->ib_window_map)
> + return -ENOMEM;
> +
> + ep->ob_window_map = devm_kzalloc(dev, sizeof(long) *
> + BITS_TO_LONGS(ep->num_ob_windows),
> + GFP_KERNEL);
> + if (!ep->ob_window_map)
> +
Re: [PATCH 0/3] S390-DASD: Fine-tuning for some function implementations
On Thu, Dec 14, 2017 at 11:34:01AM +0100, SF Markus Elfring wrote: > > Date: Wed, 10 May 2017 19:43:21 +0200 > > > > A few update suggestions were taken into account > > from static source code analysis. > > > > Markus Elfring (3): > > Adjust buffer output in dasd_hosts_print() > > Fix typos in two comment lines > > Adjust six checks for null pointers > > > > drivers/s390/block/dasd_eckd.c | 24 +++- > > 1 file changed, 11 insertions(+), 13 deletions(-) > > > Are there any chances that such change possibilities (and further adjustments) > will be integrated in this software area? No.
Re: [PATCH v4 2/3] PCI: endpoint: Fix error handling in pci_epc_epf_link()
Hi Niklas,
On Tuesday 12 December 2017 07:46 PM, Niklas Cassel wrote:
> The error handling in pci_epc_epf_link() is broken,
> since the clean up code for pci_epc_add_epf() calls clear_bit(),
> even though the matching set_bit() is done after pci_epc_add_epf().
>
> Also, clear_bit() should be done before pci_epc_remove_epf(),
> since clean up code should normally do things in the reverse order.
>
> Fixes: d74679911610 ("PCI: endpoint: Introduce configfs entry for configuring
> EP functions")
> Signed-off-by: Niklas Cassel
> Acked-by: Lorenzo Pieralisi
> ---
> drivers/pci/endpoint/pci-ep-cfs.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/pci/endpoint/pci-ep-cfs.c
> b/drivers/pci/endpoint/pci-ep-cfs.c
> index 4f74386c1ced..e1f5adc9e113 100644
> --- a/drivers/pci/endpoint/pci-ep-cfs.c
> +++ b/drivers/pci/endpoint/pci-ep-cfs.c
> @@ -106,7 +106,7 @@ static int pci_epc_epf_link(struct config_item *epc_item,
> epf = epf_group->epf;
> ret = pci_epc_add_epf(epc, epf);
> if (ret)
> - goto err_add_epf;
> + return ret;
Actually the func_no should be populated before invoking pci_epc_add_epf. Once
that is done, the error handling should be fine.
Thanks
Kishon
Re: [PATCH v4 3/3] PCI: endpoint: Fix find_first_zero_bit() usage
On Tuesday 12 December 2017 07:46 PM, Niklas Cassel wrote:
> find_first_zero_bit()'s parameter 'size' is defined in bits,
> not in bytes.
>
> Calling find_first_zero_bit() with the wrong size unit
> will lead to insidious bugs.
>
> Fix this by calling find_first_zero_bit() with size BITS_PER_LONG,
> rather than sizeof() and add missing find_first_zero_bit() return
> handling.
>
> Fixes: d74679911610 ("PCI: endpoint: Introduce configfs entry for configuring
> EP functions")
> Signed-off-by: Niklas Cassel
> Acked-by: Lorenzo Pieralisi
I'll hold Acking this patch, since it is dependent on the previous one.
Thanks
Kishon
Re: [PATCH 1/3] dt-bindings: ARM: Mediatek: Fix ethsys documentation
Hi Stephen, Michael,
On 12/01/2017 01:07 PM, Matthias Brugger wrote:
> The ethsys registers a reset controller, so we need to specify a
> reset cell. This patch fixes the documentation.
>
> Signed-off-by: Matthias Brugger
> ---
> Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
> a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
> b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
> index 7aa3fa167668..6cc7840ff37a 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,ethsys.txt
> @@ -20,4 +20,5 @@ ethsys: clock-controller@1b00 {
> compatible = "mediatek,mt2701-ethsys", "syscon";
> reg = <0 0x1b00 0 0x1000>;
> #clock-cells = <1>;
> + #reset-cells = <1>;
> };
>
Will you take this patch through the clk tree, or shall I take it through my SoC
tree?
Regards,
Matthias
[PATCH V2] mm/mprotect: Add a cond_resched() inside change_pmd_range()
While testing on a large CPU system, detected the following RCU stall many times over the span of the workload. This problem is solved by adding a cond_resched() in the change_pmd_range() function. [ 850.962530] INFO: rcu_sched detected stalls on CPUs/tasks: [ 850.962584] 154-: (670 ticks this GP) idle=022/140/0 softirq=2825/2825 fqs=612 [ 850.962605] (detected by 955, t=6002 jiffies, g=4486, c=4485, q=90864) [ 850.962895] Sending NMI from CPU 955 to CPUs 154: [ 850.992667] NMI backtrace for cpu 154 [ 850.993069] CPU: 154 PID: 147071 Comm: workload Not tainted 4.15.0-rc3+ #3 [ 850.993258] NIP: c00b3f64 LR: c00b33d4 CTR: aa18 [ 850.993503] REGS: a4b0fb44 TRAP: 0501 Not tainted (4.15.0-rc3+) [ 850.993707] MSR: 80009033 CR: 22422082 XER: [ 850.994386] CFAR: 006cf8f0 SOFTE: 1 GPR00: 0010 c3ef9b1cb8c0 c10cc600 GPR04: 8e018c32b200 40017b3858fd6e00 8e018c32b208 40017b3858fd6e00 GPR08: 8e018c32b210 40017b3858fd6e00 8e018c32b218 40017b3858fd6e00 GPR12: cfb25100 [ 850.995976] NIP [c00b3f64] plpar_hcall9+0x44/0x7c [ 850.996174] LR [c00b33d4] pSeries_lpar_flush_hash_range+0x384/0x420 [ 850.996401] Call Trace: [ 850.996600] [c3ef9b1cb8c0] [c3fa8fff7d40] 0xc3fa8fff7d40 (unreliable) [ 850.996959] [c3ef9b1cba40] [c00688a8] flush_hash_range+0x48/0x100 [ 850.997261] [c3ef9b1cba90] [c0071b14] __flush_tlb_pending+0x44/0xd0 [ 850.997600] [c3ef9b1cbac0] [c0071fa8] hpte_need_flush+0x408/0x470 [ 850.997958] [c3ef9b1cbb30] [c02c646c] change_protection_range+0xaac/0xf10 [ 850.998180] [c3ef9b1cbcb0] [c02f2510] change_prot_numa+0x30/0xb0 [ 850.998502] [c3ef9b1cbce0] [c013a950] task_numa_work+0x2d0/0x3e0 [ 850.998816] [c3ef9b1cbda0] [c011ea30] task_work_run+0x130/0x190 [ 850.999121] [c3ef9b1cbe00] [c001bcd8] do_notify_resume+0x118/0x120 [ 850.999421] [c3ef9b1cbe30] [c000b744] ret_from_except_lite+0x70/0x74 [ 850.999716] Instruction dump: [ 850.59] 6000 f8810028 7ca42b78 7cc53378 7ce63b78 7d074378 7d284b78 7d495378 [ 851.000575] e9410060 e9610068 e9810070 4422 <7d806378> e9810028 f88c f8ac0008 Suggested-by: Nicholas Piggin Signed-off-by: Anshuman Khandual --- Changes in V2: - Moved cond_resched() to change_pmd_range() as per Michal Hocko - Fixed commit message as appropriate Changes in V1: (https://patchwork.kernel.org/patch/10111445/) mm/mprotect.c | 1 + 1 file changed, 1 insertion(+) diff --git a/mm/mprotect.c b/mm/mprotect.c index ec39f73..43c29fa 100644 --- a/mm/mprotect.c +++ b/mm/mprotect.c @@ -196,6 +196,7 @@ static inline unsigned long change_pmd_range(struct vm_area_struct *vma, this_pages = change_pte_range(vma, pmd, addr, next, newprot, dirty_accountable, prot_numa); pages += this_pages; + cond_resched(); } while (pmd++, addr = next, addr != end); if (mni_start) -- 2.9.3
Re: [PATCH 14/19] xfs: convert to new i_version API
On Thu, 2017-12-14 at 13:17 +1100, Dave Chinner wrote:
> On Wed, Dec 13, 2017 at 07:10:22PM -0500, Jeff Layton wrote:
> > On Thu, 2017-12-14 at 10:25 +1100, Dave Chinner wrote:
> > > So now I've looked at the last patch .
> > >
> > > On Thu, Dec 14, 2017 at 09:48:37AM +1100, Dave Chinner wrote:
> > > > On Wed, Dec 13, 2017 at 09:20:12AM -0500, Jeff Layton wrote:
> > > > > From: Jeff Layton
> > > > >
> > > > > Signed-off-by: Jeff Layton
> > > > > ---
> > > > > fs/xfs/libxfs/xfs_inode_buf.c | 5 +++--
> > > > > fs/xfs/xfs_icache.c | 4 ++--
> > > > > fs/xfs/xfs_inode.c| 2 +-
> > > > > fs/xfs/xfs_inode_item.c | 2 +-
> > > > > fs/xfs/xfs_trans_inode.c | 2 +-
> > > > > 5 files changed, 8 insertions(+), 7 deletions(-)
> > > > >
> > > > > diff --git a/fs/xfs/libxfs/xfs_inode_buf.c
> > > > > b/fs/xfs/libxfs/xfs_inode_buf.c
> > > > > index 6b7989038d75..6b47de201391 100644
> > > > > --- a/fs/xfs/libxfs/xfs_inode_buf.c
> > > > > +++ b/fs/xfs/libxfs/xfs_inode_buf.c
> > > > > @@ -264,7 +264,8 @@ xfs_inode_from_disk(
> > > > > to->di_flags= be16_to_cpu(from->di_flags);
> > > > >
> > > > > if (to->di_version == 3) {
> > > > > - inode->i_version = be64_to_cpu(from->di_changecount);
> > > > > + inode_set_iversion_queried(inode,
> > > > > +
> > > > > be64_to_cpu(from->di_changecount));
> > > >
> > > > So we use the "kernel managed" (really not sure what that means)
> > > > set function here to read it off disk, but...
> > >
> > > This stores the value from disk in the incore inode as "val << 1",
> > > then sets the lowest bit to indicate that it has been "queried"
> > > so that it will be incremented on the first modification.
> > >
> > > Why do we initialise values read from disk as "queried"? This means
> > > the i_version will change once every time it's brought into memory
> > > and modified, regardless of whether anyone is looking at it. What
> > > purpose does this serve?
> > >
> >
> > I don't think we want to store the QUERIED bit.
> >
> > It's always possible that we crash at an inopportune time and a query
> > happened vs. this value before this thing hit the backing store.
> >
> > If we always set the queried bit when we load it from disk, then we know
> > that that scenario is harmless, at the negligible expense of having to
> > bump it on the first write.
>
> Reasonable. Needs documentation.
>
Will do.
FWIW, there's another reason to do it this way too: backward
compatibility. If we don't try to store the queried bit then we should
be able to go back and forth between legacy kernels and the ones with
the new i_version handling without any trouble. The older kernels will
just bump the count more frequently.
> > > > > diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
> > > > > index 801274126648..be6d87980dd5 100644
> > > > > --- a/fs/xfs/xfs_inode.c
> > > > > +++ b/fs/xfs/xfs_inode.c
> > > > > @@ -833,7 +833,7 @@ xfs_ialloc(
> > > > > ip->i_d.di_flags = 0;
> > > > >
> > > > > if (ip->i_d.di_version == 3) {
> > > > > - inode->i_version = 1;
> > > > > + inode_set_iversion(inode, 1);
> > > >
> > > > But here you are using the "filesystem managed" mdoe to set the
> > > > new value. Why? How is this any different from reading the value
> > > > off disk and setting it?
> > >
> > > Still don't understand why this is different to reading the inode
> > > from disk
> >
> > This is a allocating a brand new, never before seen inode. There's no
> > way this i_version could have ever been seen, so there's no need to flag
> > it as queried.
>
> More documentation. People are going to need to know this stuff to
> be able to implement/maintain this stuff in working order - it's no
> longer a simple, obvious "just increment the counter on
> modification" variable and that has potential ramifications for
> filesystems that store this on disk.
>
>
Definitely. I'm finding that documenting this has been the hardest part.
Thanks for the review so far!
--
Jeff Layton
Re: [PATCH v2 1/3] mmc: dt-bindings: add mmc support to MT7623 SoC
Hi Ulf, On 12/07/2017 07:43 AM, sean.w...@mediatek.com wrote: > From: Sean Wang > > Add the devicetree binding for MT7623 SoC using MT2701 as the fallback. > > Cc: devicet...@vger.kernel.org > Signed-off-by: Sean Wang > Acked-by: Rob Herring > --- > Documentation/devicetree/bindings/mmc/mtk-sd.txt | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt > b/Documentation/devicetree/bindings/mmc/mtk-sd.txt > index 72d2a73..9b80176 100644 > --- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt > +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt > @@ -12,6 +12,8 @@ Required properties: > "mediatek,mt8173-mmc": for mmc host ip compatible with mt8173 > "mediatek,mt2701-mmc": for mmc host ip compatible with mt2701 > "mediatek,mt2712-mmc": for mmc host ip compatible with mt2712 > + "mediatek,mt7623-mmc", "mediatek,mt2701-mmc": for MT7623 SoC > + > - reg: physical base address of the controller and length > - interrupts: Should contain MSDC interrupt number > - clocks: Should contain phandle for the clock feeding the MMC controller > Are you fine to take this patch through your branch, or shall I take it through mine? @Sean it seems you forgot to send this patch to Ulf as well. In the future please take care to send the patch to all relevant people and mailinglist. Thanks, Matthias
Re: [PATCH 3/3] arm: dts: mt2701: Add reset-cells
On 12/01/2017 01:07 PM, Matthias Brugger wrote:
> The hifsys and ethsys needs the definition of the reset-cells
> property. Fix this.
>
> Signed-off-by: Matthias Brugger
> ---
> arch/arm/boot/dts/mt2701.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
> index 965ddfbc9953..05557fce0f1d 100644
> --- a/arch/arm/boot/dts/mt2701.dtsi
> +++ b/arch/arm/boot/dts/mt2701.dtsi
> @@ -604,6 +604,7 @@
> compatible = "mediatek,mt2701-hifsys", "syscon";
> reg = <0 0x1a00 0 0x1000>;
> #clock-cells = <1>;
> + #reset-cells = <1>;
> };
>
> usb0: usb@1a1c {
> @@ -688,6 +689,7 @@
> compatible = "mediatek,mt2701-ethsys", "syscon";
> reg = <0 0x1b00 0 0x1000>;
> #clock-cells = <1>;
> + #reset-cells = <1>;
> };
>
> eth: ethernet@1b10 {
>
2 and 3 pushed to v4.15-next/dts32
Thanks!
Re: [PATCH v2 3/3] arm: dts: mt7623: fix card detection issue on bananapi-r2
On 12/07/2017 07:43 AM, sean.w...@mediatek.com wrote:
> From: Sean Wang
>
> Fix that bananapi-r2 booting from SD-card would fail since incorrect
> polarity is applied to the previous setup with GPIO_ACTIVE_HIGH.
>
> Cc: sta...@vger.kernel.org
> Fixes: 0eed8d097612 ("arm: dts: mt7623: Add SD-card and EMMC to bananapi-r2")
> Signed-off-by: Sean Wang
> Tested-by: Matthias Brugger
> ---
> arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> index 688a863..7bf5aa2 100644
> --- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> +++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> @@ -204,7 +204,7 @@
> bus-width = <4>;
> max-frequency = <5000>;
> cap-sd-highspeed;
> - cd-gpios = <&pio 261 0>;
> + cd-gpios = <&pio 261 GPIO_ACTIVE_LOW>;
> vmmc-supply = <&mt6323_vmch_reg>;
> vqmmc-supply = <&mt6323_vio18_reg>;
> };
>
2 and 3 pushed to v4.15-next/dts32
Thanks!
Re: [PATCH v6 00/11] Intel SGX Driver
On Tue, Dec 12, 2017 at 03:07:50PM +0100, Pavel Machek wrote: > On Sat 2017-11-25 21:29:17, Jarkko Sakkinen wrote: > > Intel(R) SGX is a set of CPU instructions that can be used by applications > > to > > set aside private regions of code and data. The code outside the enclave is > > disallowed to access the memory inside the enclave by the CPU access > > control. > > In a way you can think that SGX provides inverted sandbox. It protects the > > application from a malicious host. > > Would you list guarantees provided by SGX? > > For example, host can still observe timing of cachelines being > accessed by "protected" app, right? Can it also introduce bit flips? > > Pavel I'll put this in my backlog. Thank you. /Jarkko
Re: About the try to remove cross-release feature entirely by Ingo
On Wed, Dec 13, 2017 at 10:07:11PM -0500, Theodore Ts'o wrote: > interpreted this as the lockdep maintainers saying, "hey, not my > fault, it's the subsystem maintainer's fault for not properly > classifying the locks" --- and thus dumping the responsibility in the > subsystem maintainers' laps. Let me clarify that I (as lockdep maintainer) disagree with that sentiment. I have spend a lot of time over the years staring at random code trying to fix lockdep splats. Its awesome if corresponding subsystem maintainers help out and many have, but I very much do not agree its their problem and their problem alone. This attitude is one of the biggest issues I have with the crossrelease stuff and why I don't disagree with Ingo taking it out (for now).
Re: [PATCH] PCI: qcom: add missing supplies required for msm8996
On 14/12/17 10:06, Stanimir Varbanov wrote:
Hi Srini,
On 12/08/2017 11:20 AM, srinivas.kandaga...@linaro.org wrote:
From: Srinivas Kandagatla
This patch adds supplies that are required for msm8996. Two of them vdda
and vdda-1p8 are analog supplies that go in to controller, and the rest
According to the msm8996 device specification there are two pins related
to the PCIe power: VDD_PCIE_CORE (power for PCIe core circuitry) and
VDD_PCIE_1P8 (power for PCIe I/O circuitry). Thus I think it is clear
that VDD_PCIE_CORE is vdda and VDD_PCIE_1P8 should be part of PCIe phy
driver DT binding (and this is the case currently [1]). So I don't think
we need vdda-1p8 regulator DT binding for that in pcie-qcom.
Sure I will remove it.
of the two vddpe's are supplies to PCIe endpoints.
For this part I'm still not sure. On first sight it looks that these
vdd's should be part of endpoint drivers, on the other hand we have
mPCIe connector (on db820c) which has two power rails 3p3v and 1p5v
which should be controlled/enabled as well.
Yes, these would be populated in DT as part of vddpe supplies for that lane.
So I'd like to hear more opinions on that, i.e. how this is solved by
the other PCIe bridge drivers.
I would be keen on knowing more options to solve this neatly too!!
This is only problem with DT and PCIE device discovery to start with!!
We are in catch 22 situation, where in we can not enumerate device
without it actually powering up.
All the other controllers like SDIO, MMC use something similar to enable
these regulators. SDIO actually uses pwrseq to do this.
There was attempt to generalize pwrseq to other subsystems, not sure
where it landed.
As of today, the only way to power up endpoint in sync with reset is via
controller driver, all other ways we would end up doing reset out of
sync with power which are error prone.
- phys:
Usage: required for apq8084
@@ -205,6 +219,8 @@
Value type:
Definition: List of phandle and GPIO specifier pairs. Should contain
- "perst-gpios" PCIe endpoint reset signal line
+ - "pe_en-gpios" PCIe endpoint enable signal line
+ - "pe_en1-gpios" PCIe endpoint enable1 signal line
those two shouldn't be here, instead they should be part of regulator DT
node, so please drop them.
Yes, I can drop them for now!
- "wake-gpios"PCIe endpoint wake signal line
* Example for ipq/apq8064
diff --git a/drivers/pci/dwc/pcie-qcom.c b/drivers/pci/dwc/pcie-qcom.c
index 952a4fc4bf3c..01488f90da31 100644
--- a/drivers/pci/dwc/pcie-qcom.c
+++ b/drivers/pci/dwc/pcie-qcom.c
@@ -109,13 +109,15 @@ struct qcom_pcie_resources_1_0_0 {
struct reset_control *core;
struct regulator *vdda;
};
-
+#define QCOM_PCIE_MAX_SUPPLY 4
struct qcom_pcie_resources_2_3_2 {
struct clk *aux_clk;
struct clk *master_clk;
struct clk *slave_clk;
struct clk *cfg_clk;
struct clk *pipe_clk;
+ int num_supplies;
+ struct regulator_bulk_data supplies[QCOM_PCIE_MAX_SUPPLY];
};
struct qcom_pcie_resources_2_4_0 {
@@ -529,6 +531,17 @@ static int qcom_pcie_get_resources_2_3_2(struct qcom_pcie
*pcie)
struct qcom_pcie_resources_2_3_2 *res = &pcie->res.v2_3_2;
struct dw_pcie *pci = pcie->pci;
struct device *dev = pci->dev;
+ int ret;
+
+ res->supplies[0].supply = "vdda";
+ res->supplies[1].supply = "vdda-1p8";
+ res->supplies[2].supply = "vddpe";
+ res->supplies[3].supply = "vddpe1";
+ res->num_supplies = QCOM_PCIE_MAX_SUPPLY;
+ ret = devm_regulator_bulk_get(dev, QCOM_PCIE_MAX_SUPPLY,
+ res->supplies);
If we decide to go on this direction we need to replace this with
devm_regulator_bulk_get_optional (yes I know there is no such regulator
API yet) because they are optional in the DT binding.
I think the api name is misleading here, actually
devm_regulator_bulk_get() will return dummy regulators if the regulators
are not present, so code as it is Okay. On the other hand *_optonal api
would fail.
thanks,
srini
Re: [BISECTED] tpm CLKRUN breaks PS/2 keyboard and touchpad on Braswell system
On Mon, Dec 11, 2017 at 07:37:29PM +, James Ettle wrote:
> Hello,
>
> [First: Apologies if cross-posting from Kernel.org BZ is bad form; my
> distro BZ advised I post this to your mailing list as well.]
>
> Situation: enabling TPM on a Clevo W510LU with an Intel N3160 CPU
> breaks PS/2 keyboard and mouse. They just don't respond until after a
> suspend/resume cycle, and after that they later stop after a while.
>
> I have confirmed this by blacklisting tpm modules. I noticed this
> first with kernel 4.13, and have bisected it down to:
In my GIT tree there is now:
commit db3248e8a036c39141c8f7e9f1cf5c5ae6815f76 (HEAD -> next, origin/next,
origin/master, master)
Author: Azhar Shaikh
Date: Wed Dec 6 17:38:10 2017 -0800
tpm: Keep CLKRUN enabled throughout the duration of transmit_cmd()
Commit 5e572cab92f0bb5 ("tpm: Enable CLKRUN protocol for Braswell
systems") disabled CLKRUN protocol during TPM transactions and re-enabled
once the transaction is completed. But there were still some corner cases
observed where, reading of TPM header failed for savestate command
while going to suspend, which resulted in suspend failure.
To fix this issue keep the CLKRUN protocol disabled for the entire
duration of a single TPM command and not disabling and re-enabling
again for every TPM transaction. For the other TPM accesses outside
TPM command flow, add a higher level of disabling and re-enabling
the CLKRUN protocol, instead of doing for every TPM transaction.
Fixes: 5e572cab92f0bb5 ("tpm: Enable CLKRUN protocol for Braswell systems")
Signed-off-by: Azhar Shaikh
Reviewed-by: Jarkko Sakkinen
Tested-by: Jarkko Sakkinen
Signed-off-by: Jarkko Sakkinen
Can you try this?
/Jarkko
Re: [PATCH 1/2] thermal: mtk: Cleanup unused defines
On 12/01/2017 11:43 AM, Matthias Brugger wrote:
> The mtk_thermal has some defiens which are never used within the driver.
> This patch delets them.
>
> Signed-off-by: Matthias Brugger
> ---
> drivers/thermal/mtk_thermal.c | 9 +
> 1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
> index 1e61c09153c9..c75661a3801a 100644
> --- a/drivers/thermal/mtk_thermal.c
> +++ b/drivers/thermal/mtk_thermal.c
> @@ -32,15 +32,10 @@
> #include
>
> /* AUXADC Registers */
> -#define AUXADC_CON0_V0x000
> -#define AUXADC_CON1_V0x004
> #define AUXADC_CON1_SET_V0x008
> #define AUXADC_CON1_CLR_V0x00c
> #define AUXADC_CON2_V0x010
> #define AUXADC_DATA(channel) (0x14 + (channel) * 4)
> -#define AUXADC_MISC_V0x094
> -
> -#define AUXADC_CON1_CHANNEL(x) BIT(x)
>
> #define APMIXED_SYS_TS_CON1 0x604
>
> @@ -158,8 +153,6 @@
> /* The number of sensing points per bank */
> #define MT2712_NUM_SENSORS_PER_ZONE 4
>
> -#define THERMAL_NAME"mtk-thermal"
> -
> struct mtk_thermal;
>
> struct thermal_bank_cfg {
> @@ -765,7 +758,7 @@ static struct platform_driver mtk_thermal_driver = {
> .probe = mtk_thermal_probe,
> .remove = mtk_thermal_remove,
> .driver = {
> - .name = THERMAL_NAME,
> + .name = "mtk-thermal",
> .of_match_table = mtk_thermal_of_match,
> },
> };
>
Kind ping.
RE: [PATCH 6/8] remoteproc: Move resource table load logic to find
> -Original Message-
> From: linux-remoteproc-ow...@vger.kernel.org [mailto:linux-remoteproc-
> ow...@vger.kernel.org] On Behalf Of Bjorn Andersson
> Sent: Wednesday, December 13, 2017 11:41 PM
> To: Ohad Ben-Cohen ; Bjorn Andersson
>
> Cc: linux-remotep...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [PATCH 6/8] remoteproc: Move resource table load logic to find
>
> Extend the previous operation of finding the resource table in the ELF
> with the extra step of populating the rproc struct with a copy and the
> size. This allows drivers to override the mechanism used for acquiring
> the resource table, or omit it for firmware that is known not to have a
> resource table.
>
> This leaves the custom, dummy, find_rsc_table implementations found in
> some drivers dangling.
>
> Signed-off-by: Bjorn Andersson
> ---
> drivers/remoteproc/remoteproc_core.c | 32 ++
> drivers/remoteproc/remoteproc_elf_loader.c | 37 ++--
> --
> drivers/remoteproc/remoteproc_internal.h | 16 +
> include/linux/remoteproc.h | 1 +
> 4 files changed, 36 insertions(+), 50 deletions(-)
>
> diff --git a/drivers/remoteproc/remoteproc_core.c
> b/drivers/remoteproc/remoteproc_core.c
> index 63d88d1d206e..cbd12382b219 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -907,8 +907,7 @@ static int rproc_fw_boot(struct rproc *rproc, const
> struct firmware *fw)
> {
> struct device *dev = &rproc->dev;
> const char *name = rproc->firmware;
> - struct resource_table *table;
> - int ret, tablesz;
> + int ret;
>
> ret = rproc_fw_sanity_check(rproc, fw);
> if (ret)
> @@ -927,27 +926,11 @@ static int rproc_fw_boot(struct rproc *rproc, const
> struct firmware *fw)
> }
>
> rproc->bootaddr = rproc_get_boot_addr(rproc, fw);
> - ret = -EINVAL;
> -
> - /* look for the resource table */
> - table = rproc_find_rsc_table(rproc, fw, &tablesz);
> - if (!table) {
> - dev_err(dev, "Failed to find resource table\n");
> - goto clean_up;
> - }
> -
> - /*
> - * Create a copy of the resource table. When a virtio device starts
> - * and calls vring_new_virtqueue() the address of the allocated vring
> - * will be stored in the cached_table. Before the device is started,
> - * cached_table will be copied into device memory.
> - */
> - rproc->cached_table = kmemdup(table, tablesz, GFP_KERNEL);
> - if (!rproc->cached_table)
> - goto clean_up;
>
> - rproc->table_ptr = rproc->cached_table;
> - rproc->table_sz = tablesz;
> + /* load resource table */
> + ret = rproc_load_rsc_table(rproc, fw);
> + if (ret)
> + goto disable_iommu;
>
> /* reset max_notifyid */
> rproc->max_notifyid = -1;
> @@ -967,11 +950,10 @@ static int rproc_fw_boot(struct rproc *rproc, const
> struct firmware *fw)
>
> clean_up_resources:
> rproc_resource_cleanup(rproc);
> -clean_up:
> kfree(rproc->cached_table);
> rproc->cached_table = NULL;
> rproc->table_ptr = NULL;
> -
> +disable_iommu:
> rproc_disable_iommu(rproc);
> return ret;
> }
> @@ -1443,7 +1425,7 @@ struct rproc *rproc_alloc(struct device *dev, const
> char *name,
> /* Default to ELF loader if no load function is specified */
> if (!rproc->ops->load) {
> rproc->ops->load = rproc_elf_load_segments;
> - rproc->ops->find_rsc_table = rproc_elf_find_rsc_table;
> + rproc->ops->load_rsc_table = rproc_elf_load_rsc_table;
> rproc->ops->find_loaded_rsc_table =
> rproc_elf_find_loaded_rsc_table;
> rproc->ops->sanity_check = rproc_elf_sanity_check;
> rproc->ops->get_boot_addr = rproc_elf_get_boot_addr;
> diff --git a/drivers/remoteproc/remoteproc_elf_loader.c
> b/drivers/remoteproc/remoteproc_elf_loader.c
> index 822fa1bf893f..b17d72ec8603 100644
> --- a/drivers/remoteproc/remoteproc_elf_loader.c
> +++ b/drivers/remoteproc/remoteproc_elf_loader.c
> @@ -268,42 +268,49 @@ find_table(struct device *dev, struct elf32_hdr
> *ehdr, size_t fw_size)
> }
>
> /**
> - * rproc_elf_find_rsc_table() - find the resource table
> + * rproc_elf_load_rsc_table() - load the resource table
> * @rproc: the rproc handle
> * @fw: the ELF firmware image
> - * @tablesz: place holder for providing back the table size
> *
> * This function finds the resource table inside the remote processor's
> - * firmware. It is used both upon the registration of @rproc (in order
> - * to look for and register the supported virito devices), and when the
> - * @rproc is booted.
> + * firmware, load it into the @cached_table and update @table_ptr.
> *
> - * Returns the pointer to the resource table if it is found, and write its
> - * size into @tablesz. If a valid table isn't found, NULL is returned
> - * (and @table
