* [linux-sunxi] [PATCH v5 4/7] ASoC: sunxi: Add sun8i I2S driver
From: Maxime Ripard @ 2016-11-14 21:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161108115129.f315ca5feefd22614859bbe3@free.fr>
On Tue, Nov 08, 2016 at 11:51:29AM +0100, Jean-Francois Moine wrote:
> On Mon, 7 Nov 2016 21:05:05 +0100
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>
> > Hi,
> >
> > On Sun, Nov 06, 2016 at 07:02:48PM +0100, Jean-Francois Moine wrote:
> > > On Sun, 23 Oct 2016 09:33:16 +0800
> > > Chen-Yu Tsai <wens@csie.org> wrote:
> > >
> > > > On Fri, Oct 21, 2016 at 4:36 PM, Jean-Francois Moine <moinejf@free.fr> wrote:
> > > > > This patch adds I2S support to sun8i SoCs as the A83T and H3.
> > > > >
> > > > > Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> > > > > ---
> > > > > Note: This driver is closed to the sun4i-i2s except that:
> > > > > - it handles the H3
> > > >
> > > > If it's close to sun4i-i2s, you should probably rework that one to support
> > > > the newer SoCs.
> > >
> > > I started to add the H3 into the sun4i-i2s, but I am blocked with
> > > regmap.
> > > Many H3 registers are common with the A10, but some of them have more
> > > or less fields, the fields may be at different offsets. And, finally,
> > > some registers are completely different.
> > > This would not raise any problem, except with regmap which is really
> > > painful.
> >
> > That's weird, because regmap's regmap_field should make that much
> > easier.
>
> #define field_relaxed(addr, mask, val) \
> writel_relaxed((readl_relaxed(addr) & mask) | val, addr)
I'm not sure what you mean here.
> > > As I may understood, regmap is used to simplify suspend/resume, but, is
> > > it useful to save the I2S register on suspend?
> > > Practically, I am streaming some tune on my device. I suspend it for
> > > any reason. The next morning, I resume it. Are you sure I want to
> > > continue to hear the end of the tune?
> > >
> > > I better think that streaming should be simply stopped on suspend.
> >
> > You're mistaken. The code in there is for *runtime* suspend, ie when
> > the device is no longer used, so that case shouldn't even happen at
> > all.
> >
> > (And real suspend isn't supported anyway)
>
> Is it time to remove this useless code?
Which useless code?
> > > Then, there is no need to save the playing registers, and, here I am,
> > > there is no need to use regmap.
> > >
> > > May I go this way?
> >
> > No, please don't. regmap is also providing very useful features, such
> > as access to all the registers through debugfs, or tracing. What
> > exactly feels painful to you?
>
> When the I/O registers are in memory (that's the case), you may access
> them (read and write) thru /dev/mem.
For all the registers if you want to dump all of them. It needs
scripting, it needs root access, and it needs some tool (either devmem
or a custom one) to dump the values. And this is if you have the right
kernel configuration options (devmem enabled, with the protection
against mapped devices disabled).
It just works with debugfs.
> Also, is a register access trace really needed in this driver?
Yes.
> The pain is to define the regmap_config (which registers can be
> read/write/volatile and which can be the values the u-boot let us in
> the registers at startup time), and the lot of code which is run instead
> of simple load/store machine instructions.
This is only needed if you want to use caching, and caching is
optional.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/5cda6589/attachment.sig>
^ permalink raw reply
* Re: [PATCH v5 4/7] ASoC: sunxi: Add sun8i I2S driver
From: Maxime Ripard @ 2016-11-14 21:22 UTC (permalink / raw)
To: Jean-Francois Moine
Cc: Chen-Yu Tsai, Dave Airlie, Liam Girdwood, Mark Brown, Rob Herring,
Linux-ALSA, devicetree, dri-devel, linux-arm-kernel, linux-sunxi
In-Reply-To: <20161108115129.f315ca5feefd22614859bbe3-GANU6spQydw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3472 bytes --]
On Tue, Nov 08, 2016 at 11:51:29AM +0100, Jean-Francois Moine wrote:
> On Mon, 7 Nov 2016 21:05:05 +0100
> Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>
> > Hi,
> >
> > On Sun, Nov 06, 2016 at 07:02:48PM +0100, Jean-Francois Moine wrote:
> > > On Sun, 23 Oct 2016 09:33:16 +0800
> > > Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
> > >
> > > > On Fri, Oct 21, 2016 at 4:36 PM, Jean-Francois Moine <moinejf-GANU6spQydw@public.gmane.org> wrote:
> > > > > This patch adds I2S support to sun8i SoCs as the A83T and H3.
> > > > >
> > > > > Signed-off-by: Jean-Francois Moine <moinejf-GANU6spQydw@public.gmane.org>
> > > > > ---
> > > > > Note: This driver is closed to the sun4i-i2s except that:
> > > > > - it handles the H3
> > > >
> > > > If it's close to sun4i-i2s, you should probably rework that one to support
> > > > the newer SoCs.
> > >
> > > I started to add the H3 into the sun4i-i2s, but I am blocked with
> > > regmap.
> > > Many H3 registers are common with the A10, but some of them have more
> > > or less fields, the fields may be at different offsets. And, finally,
> > > some registers are completely different.
> > > This would not raise any problem, except with regmap which is really
> > > painful.
> >
> > That's weird, because regmap's regmap_field should make that much
> > easier.
>
> #define field_relaxed(addr, mask, val) \
> writel_relaxed((readl_relaxed(addr) & mask) | val, addr)
I'm not sure what you mean here.
> > > As I may understood, regmap is used to simplify suspend/resume, but, is
> > > it useful to save the I2S register on suspend?
> > > Practically, I am streaming some tune on my device. I suspend it for
> > > any reason. The next morning, I resume it. Are you sure I want to
> > > continue to hear the end of the tune?
> > >
> > > I better think that streaming should be simply stopped on suspend.
> >
> > You're mistaken. The code in there is for *runtime* suspend, ie when
> > the device is no longer used, so that case shouldn't even happen at
> > all.
> >
> > (And real suspend isn't supported anyway)
>
> Is it time to remove this useless code?
Which useless code?
> > > Then, there is no need to save the playing registers, and, here I am,
> > > there is no need to use regmap.
> > >
> > > May I go this way?
> >
> > No, please don't. regmap is also providing very useful features, such
> > as access to all the registers through debugfs, or tracing. What
> > exactly feels painful to you?
>
> When the I/O registers are in memory (that's the case), you may access
> them (read and write) thru /dev/mem.
For all the registers if you want to dump all of them. It needs
scripting, it needs root access, and it needs some tool (either devmem
or a custom one) to dump the values. And this is if you have the right
kernel configuration options (devmem enabled, with the protection
against mapped devices disabled).
It just works with debugfs.
> Also, is a register access trace really needed in this driver?
Yes.
> The pain is to define the regmap_config (which registers can be
> read/write/volatile and which can be the values the u-boot let us in
> the registers at startup time), and the lot of code which is run instead
> of simple load/store machine instructions.
This is only needed if you want to use caching, and caching is
optional.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 5/5] PCI: Balance ports to avoid ACS errata on Pericom switches
From: Alex Williamson @ 2016-11-14 21:21 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: linux-pci, bhelgaas, iommu, linux-kernel
In-Reply-To: <20161114210319.GC9868@bhelgaas-glaptop.roam.corp.google.com>
On Mon, 14 Nov 2016 15:03:19 -0600
Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Wed, Oct 26, 2016 at 12:01:40PM -0600, Alex Williamson wrote:
> > As described in the included code comment, this quirk is intended to
> > work around an errata in a variety of Pericom 4-lane, 3 and 4 port
> > PCIe 2.0 switches. The switches advertise ACS capabilities, but the
> > P2P Request Redirection support includes an errata that PCI_ACS_RR
> > effectively doesn't work and results in transactions being queued and
> > not delivered within the PCIe switch. The errata has no planned
> > hardware fix.
>
> Is there a published erratum we can reference here? It'd be really
> nice to have a URL.
Unfortunately only the product briefs seem to be public. I was sent an
errata, but it's marked confidential, so I don't think I'll risk adding
it to the bz. I haven't even been granted access to the datasheet.
I'm only guessing at the affected devices IDs based on my sample of one.
One thing I've thought of since I posted this series is that it's
possible to have a configuration where the downstream ports don't all
match. If the upstream port is running at 5GT/s, the first downstream
port is also running 5GT/s, but another downstream port is running
2.5GT/s, this code will retrain the upstream port to 2.5GT/s w/o
revisiting that first port. I should fix that, but I likely won't have
time for v4.10. If you want to de-queue this, I'll try to look at it
again for v4.11 and take your other suggestions into account. Thanks,
Alex
^ permalink raw reply
* Re: [PATCH 5/5] PCI: Balance ports to avoid ACS errata on Pericom switches
From: Alex Williamson @ 2016-11-14 21:21 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, linux-pci-u79uwXL29TY76Z2rM5mHXA,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161114210319.GC9868-1RhO1Y9PlrlHTL0Zs8A6p5iNqAH0jzoTYJqu5kTmcBRl57MIdRCFDg@public.gmane.org>
On Mon, 14 Nov 2016 15:03:19 -0600
Bjorn Helgaas <helgaas-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> On Wed, Oct 26, 2016 at 12:01:40PM -0600, Alex Williamson wrote:
> > As described in the included code comment, this quirk is intended to
> > work around an errata in a variety of Pericom 4-lane, 3 and 4 port
> > PCIe 2.0 switches. The switches advertise ACS capabilities, but the
> > P2P Request Redirection support includes an errata that PCI_ACS_RR
> > effectively doesn't work and results in transactions being queued and
> > not delivered within the PCIe switch. The errata has no planned
> > hardware fix.
>
> Is there a published erratum we can reference here? It'd be really
> nice to have a URL.
Unfortunately only the product briefs seem to be public. I was sent an
errata, but it's marked confidential, so I don't think I'll risk adding
it to the bz. I haven't even been granted access to the datasheet.
I'm only guessing at the affected devices IDs based on my sample of one.
One thing I've thought of since I posted this series is that it's
possible to have a configuration where the downstream ports don't all
match. If the upstream port is running at 5GT/s, the first downstream
port is also running 5GT/s, but another downstream port is running
2.5GT/s, this code will retrain the upstream port to 2.5GT/s w/o
revisiting that first port. I should fix that, but I likely won't have
time for v4.10. If you want to de-queue this, I'll try to look at it
again for v4.11 and take your other suggestions into account. Thanks,
Alex
^ permalink raw reply
* Re: [PATCH v2 0/2] bnx2: Wait for in-flight DMA to complete at probe stage
From: David Miller @ 2016-11-14 21:21 UTC (permalink / raw)
To: bhe
Cc: netdev, michael.chan, linux-kernel, Dept-GELinuxNICDev,
rasesh.mody, harish.patil, frank, jsr, pmenzel, jroedel, dyoung
In-Reply-To: <1479013293-21001-1-git-send-email-bhe@redhat.com>
From: Baoquan He <bhe@redhat.com>
Date: Sun, 13 Nov 2016 13:01:31 +0800
> This is v2 post.
>
> In commit 3e1be7a ("bnx2: Reset device during driver initialization"),
> firmware requesting code was moved from open stage to probe stage.
> The reason is in kdump kernel hardware iommu need device be reset in
> driver probe stage, otherwise those in-flight DMA from 1st kernel
> will continue going and look up into the newly created io-page tables.
> However bnx2 chip resetting involves firmware requesting issue, that
> need be done in open stage.
>
> Michale Chan suggested we can just wait for the old in-flight DMA to
> complete at probe stage, then though without device resetting, we
> don't need to worry the old in-flight DMA could continue looking up
> the newly created io-page tables.
>
> v1->v2:
> Michael suggested to wait for the in-flight DMA to complete at probe
> stage. So give up the old method of trying to reset chip at probe
> stage, take the new way accordingly.
Series applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: ✗ Fi.CI.BAT: warning for series starting with [CI,01/10] drm/i915: Give each sw_fence its own lockclass
From: Chris Wilson @ 2016-11-14 21:21 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <20161114211608.16476.40375@emeril.freedesktop.org>
On Mon, Nov 14, 2016 at 09:16:08PM -0000, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [CI,01/10] drm/i915: Give each sw_fence its own lockclass
> URL : https://patchwork.freedesktop.org/series/15303/
> State : warning
>
> == Summary ==
>
> Series 15303v1 Series without cover letter
> https://patchwork.freedesktop.org/api/1.0/series/15303/revisions/1/mbox/
>
> Test drv_module_reload_basic:
> pass -> DMESG-WARN (fi-skl-6770hq)
That darn lpscon
[ 36.848874] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon
[ 36.848916] [drm:intel_ddi_init [i915]] *ERROR* LSPCON init failed on port B
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [RFH] limiting ref advertisements
From: Jeff King @ 2016-11-14 21:21 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Git Mailing List
In-Reply-To: <CACsJy8DwKxz14Dow9dEKeXnBriMzN_OptnGM7nPigPcS_pHX9w@mail.gmail.com>
On Tue, Oct 25, 2016 at 06:46:21PM +0700, Duy Nguyen wrote:
> > So it seems like left-anchoring the refspecs can never be fully correct.
> > We can communicate "master" to the server, who can then look at every
> > ref it would advertise and ask "could this be called master"? But it
> > will be setting in stone the set of "could this be" patterns. Granted,
> > those haven't changed much over the history of git, but it seems awfully
> > fragile.
>
> The first thought that comes to mind is, if left anchoring does not
> work, let's support both left and right anchoring. I guess you
> considered and discarded this.
>
> If prefix matching does not work, and assuming "some-prefix" sent by
> client to be in fact "**/some-prefix" pattern at server side will set
> the "could this be" in stone, how about use wildmatch? It's flexible
> enough and we have full control over the pattern matching engine so C
> Git <-> C Git should be good regardless of platforms. I understand
> that wildmatch is still complicated enough that a re-implementation
> can easily divert in behavior. But a pattern with only '*', '/**',
> '/**/' and '**/' wildcards (in other words, no [] or ?) could make the
> engine a lot simpler and still fit our needs (and give some room for
> client-optimization).
Thanks for responding to this. I've been meaning to get back to it with
some code experiments, but they keep getting bumped down in priority. So
let me at least outline some of my thoughts, without code. :)
I was hoping to avoid right-anchoring because it's expensive to find all
of the right-anchored cases (assuming that ref storage is generally
hierarchical, which it is now and probably will be for future backends).
I also don't think it covers all cases. As bizarre as it is, I believe
you can currently do:
git fetch $remote origin
and find refs/remotes/origin/HEAD.
So I think the best we can ever do is have the server look at a specific
set of patterns. Those patterns could be expressed by wildmatch. I was
just a little nervous to turn to wildmatch, because it's complicated and
we may want to update it in the future in a slightly-incompatible way.
We also want to give some preference-order to the patterns. If I give
you "refs/heads/master", and that ref exists, you do not need to tell me
whether you also have "refs/heads/refs/heads/master". So you have to
provide multiple patterns for each possible ref. And you need to group
them as "show the first one that matches from this group".
The pattern the client is using really is the ref_rev_parse_rules. So I
think the solution is more like one of:
1. Specify the pattern set ahead of time, and then the server applies
it to each refname. We need some pattern language that can express
"fill in the thing in the middle". IOW, something like:
advertise-pattern=%s
advertise-pattern=refs/tags/%s
advertise-pattern=refs/heads/%s
advertise-lookup=master
advertise-lookup=v1.0
except that the thought of using snprintf() to handle formats
provided by the user is vaguely terrifying. We could make sure they
contain only a single "%s", but given the history there, it still
makes me nervous. I guess we could write our own pseudo-%s parser
that is much more careful and complains on bugs instead of
executing arbitrary code. ;)
I don't think wildmatch quite works for that, because it wants to
have the full pattern.
2. Declare the current set of ref_rev_parse_rules as "version 1", and
send:
advertise-lookup-v1=master
advertise-lookup-v1=v1.0
and the server would do the right thing. We could do a v2, but it
gets hairy. Let's imagine we add "refs/notes/%s" to the lookup
rules, and we'll call that v2.
But remember that these are "early capabilities", before the server
has spoken at all. So the client doesn't know if we can handle v2.
So we have to send _both_ (and v2-aware servers can ignore the v1).
advertise-lookup-v1=master
advertise-lookup-v2=master
But that's not quite enough. A v1 server won't look in refs/notes
at all. So we have to say that, too:
advertise-lookup-v1=refs/notes/master
And of course the v1 server has no idea that this isn't necessary
if we already found refs/heads/master.
So I think you really do need the client to be able to say "also
look at this pattern".
Of course we do still want left-anchoring, too. Wildcards like
"refs/heads/*" are always left-anchored. So I think we'd have two types,
and a full request for
git fetch origin +refs/heads/*:refs/remotes/origin/* master:foo
would look like:
(1) advertise-pattern-v1
(2) advertise-pattern=refs/notes/%s
(3) advertise-prefix=refs/heads
(4) advertise-lookup=master
where the lines mean:
1. Use the standard v1 patterns (we could spell them out, but this
just saves bandwidth. In fact, it could just be implicit that v1
patterns are included, and we could skip this line).
2. This is for our fictional future version where the client knows
added refs/notes/* to its DWIM but the server hasn't yet.
3. Give me all of refs/heads/*
4. Look up "master" using the advertise patterns and give me the first
one you find.
So given that we can omit (1), and that (2) is just an example for the
future, it could look like:
advertise-prefix=refs/heads
advertise-lookup=master
which is pretty reasonable. It's not _completely_ bulletproof in terms
of backwards compatibility. The "v1" thing means the client can't insert
a new pattern in the middle (remember they're ordered by priority). So
maybe it is better to spell them all out (one thing that makes me
hesitate is that these will probably end up as URL parameters for the
HTTP version, which means our URL can start to get a little long).
Anyway. That's the direction I'm thinking. I haven't written the code
yet. The trickiest thing will probably be that the server would want to
avoid advertising the same ref twice via two mechanisms (or perhaps the
client just be tolerant of duplicates; that relieves the server of any
duplicate-storage requirements).
-Peff
^ permalink raw reply
* [Buildroot] [PATCHv2] dtv-scan-tables: rename file to have only ASCII characters
From: Thomas Petazzoni @ 2016-11-14 21:20 UTC (permalink / raw)
To: buildroot
Since the bump of dtv-scan-tables to version
ceb11833b35f05813b1f0397a60e0f3b99430aab in commit
b1c8794d8ac0eb3895d13ae91d8e912ec469a105, one file contains non-ASCII
characters, which causes encoding issues tvheadend. Since no other
file in the dtv-scan-tables code base contains files with non-ASCII
characters (despite having files named after cities in various
countries that definitely do have non-ASCII characters), we rename
this file so that it is named with only ASCII characters.
This fixes the build of tvheadend, which was failing when the host
Python interpreter was python3, due to a file name encoding issue.
Fixes:
http://autobuild.buildroot.net/results/1ae8bee297edb089535a2fb6ec724ebf7976888d/
(tvheadend)
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
Changes since v1:
- use a post-patch hook instead of doing the rename at the end of the
installation step
---
package/dtv-scan-tables/dtv-scan-tables.mk | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/package/dtv-scan-tables/dtv-scan-tables.mk b/package/dtv-scan-tables/dtv-scan-tables.mk
index 8ef42b9..8a782cb 100644
--- a/package/dtv-scan-tables/dtv-scan-tables.mk
+++ b/package/dtv-scan-tables/dtv-scan-tables.mk
@@ -17,6 +17,15 @@ DTV_SCAN_TABLES_SITE_METHOD = git
DTV_SCAN_TABLES_LICENSE = GPLv2, LGPLv2.1
DTV_SCAN_TABLES_LICENSE_FILES = COPYING COPYING.LGPL
+# In order to avoid issues with file name encodings, we rename the
+# only dtv-scan-tables file that has non-ASCII characters to have a
+# name using only ASCII characters (pl-Krosno_Sucha_Gora)
+define DTV_SCAN_TABLES_FIX_NONASCII_FILENAMES
+ mv $(@D)/dvb-t/pl-Krosno_Sucha* $(@D)/dvb-t/pl-Krosno_Sucha_Gora
+endef
+
+DTV_SCAN_TABLES_POST_PATCH_HOOKS += DTV_SCAN_TABLES_FIX_NONASCII_FILENAMES
+
define DTV_SCAN_TABLES_INSTALL_TARGET_CMDS
for f in atsc dvb-c dvb-s dvb-t; do \
$(INSTALL) -d -m 0755 $(TARGET_DIR)/usr/share/dvb/$$f; \
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2] cpufreq: intel_pstate: Use cpu load based algorithm for PM_MOBILE
From: Rafael J. Wysocki @ 2016-11-14 21:20 UTC (permalink / raw)
To: Srinivas Pandruvada; +Cc: linux-pm, rdunlap, sfr, arnd, linux-kernel
In-Reply-To: <1479148271-21681-1-git-send-email-srinivas.pandruvada@linux.intel.com>
On Monday, November 14, 2016 10:31:11 AM Srinivas Pandruvada wrote:
> Use get_target_pstate_use_cpu_load() to calculate target P-State for
> devices, which uses preferred power management profile as PM_MOBILE
> in ACPI FADT.
> This may help in resolving some thermal issues caused by low sustained
> cpu bound workloads. The current algorithm tend to over provision in this
> case as it doesn't look at the CPU busyness.
>
> Also included the fix from Arnd Bergmann <arnd@arndb.de> to solve compile
> issue, when CONFIG_ACPI is not defined.
>
> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> ---
> v2:
> Include fix from Arnd Bergmann for fixing compile issue
>
> drivers/cpufreq/intel_pstate.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c
> index eb76073..9be0720 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -1828,6 +1828,19 @@ static void __init copy_pid_params(struct pstate_adjust_policy *policy)
> pid_params.setpoint = policy->setpoint;
> }
>
> +#ifdef CONFIG_ACPI
> +static void intel_pstate_use_acpi_profile(void)
> +{
> + if (acpi_gbl_FADT.preferred_profile == PM_MOBILE)
> + pstate_funcs.get_target_pstate =
> + get_target_pstate_use_cpu_load;
> +}
> +#else
> +static void intel_pstate_use_acpi_profile(void)
> +{
> +}
> +#endif
> +
> static void __init copy_cpu_funcs(struct pstate_funcs *funcs)
> {
> pstate_funcs.get_max = funcs->get_max;
> @@ -1839,6 +1852,7 @@ static void __init copy_cpu_funcs(struct pstate_funcs *funcs)
> pstate_funcs.get_vid = funcs->get_vid;
> pstate_funcs.get_target_pstate = funcs->get_target_pstate;
>
> + intel_pstate_use_acpi_profile();
> }
>
> #ifdef CONFIG_ACPI
>
I've replaced the original commit with this patch.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH] remote-curl: don't hang when a server dies before any output
From: Junio C Hamano @ 2016-11-14 21:19 UTC (permalink / raw)
To: Jeff King; +Cc: David Turner, git, spearce
In-Reply-To: <20161114194049.mktpsvgdhex2f4zv@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> So something like this. It turned out to be a lot uglier than I had
> hoped because we get fed the data from curl in odd-sized chunks, so we
> need a state machine.
It is unfortunate that we have to snoop the protocol like this to
infer an error, but I do not think we can do better than that
approach. FWIW, I did not find the logic in update_pktline_state()
you wrote ugly at all.
Having to assume that the end of each round from the other end must
be a FLUSH does feel somewhat ugly and brittle, though.
> diff --git a/remote-curl.c b/remote-curl.c
> index f14c41f4c..605357d77 100644
> --- a/remote-curl.c
> +++ b/remote-curl.c
> @@ -403,6 +403,18 @@ struct rpc_state {
> struct strbuf result;
> unsigned gzip_request : 1;
> unsigned initial_buffer : 1;
> +
> + enum {
> + RPC_PKTLINE_ERROR, /* bogus hex chars in length */
> + RPC_PKTLINE_INITIAL, /* no packets received yet */
> + RPC_PKTLINE_1, /* got one hex char */
> + RPC_PKTLINE_2, /* got two hex chars */
> + RPC_PKTLINE_3, /* got three hex chars */
> + RPC_PKTLINE_DATA, /* reading data; pktline_len holds remaining */
> + RPC_PKTLINE_END_OF_PACKET, /* last packet completed */
> + RPC_PKTLINE_FLUSH, /* last packet was flush */
> + } pktline_state;
> + size_t pktline_len;
> };
>
> static size_t rpc_out(void *ptr, size_t eltsize,
> @@ -451,11 +463,77 @@ static curlioerr rpc_ioctl(CURL *handle, int cmd, void *clientp)
> }
> #endif
>
> +static void update_pktline_state(struct rpc_state *rpc,
> + const char *buf, size_t len)
> +{
> +#define READ_ONE_HEX(shift) do { \
> + int val = hexval(buf[0]); \
> + if (val < 0) { \
> + warning("error on %d", *buf); \
> + rpc->pktline_state = RPC_PKTLINE_ERROR; \
> + return; \
> + } \
> + rpc->pktline_len |= val << shift; \
> + buf++; \
> + len--; \
> +} while(0)
> +
> + while (len > 0) {
> + switch (rpc->pktline_state) {
> + case RPC_PKTLINE_ERROR:
> + /* previous error; there is no recovery */
> + return;
> +
> + /* We can start a new pktline at any of these states */
> + case RPC_PKTLINE_INITIAL:
> + case RPC_PKTLINE_FLUSH:
> + case RPC_PKTLINE_END_OF_PACKET:
> + rpc->pktline_len = 0;
> + READ_ONE_HEX(12);
> + rpc->pktline_state = RPC_PKTLINE_1;
> + break;
> +
> + case RPC_PKTLINE_1:
> + READ_ONE_HEX(8);
> + rpc->pktline_state = RPC_PKTLINE_2;
> + break;
> +
> + case RPC_PKTLINE_2:
> + READ_ONE_HEX(4);
> + rpc->pktline_state = RPC_PKTLINE_3;
> + break;
> +
> + case RPC_PKTLINE_3:
> + READ_ONE_HEX(0);
> + if (rpc->pktline_len) {
> + rpc->pktline_state = RPC_PKTLINE_DATA;
> + rpc->pktline_len -= 4;
> + } else
> + rpc->pktline_state = RPC_PKTLINE_FLUSH;
> + break;
> +
> + case RPC_PKTLINE_DATA:
> + if (len < rpc->pktline_len) {
> + rpc->pktline_len -= len;
> + len = 0;
> + } else {
> + buf += rpc->pktline_len;
> + len -= rpc->pktline_len;
> + rpc->pktline_len = 0;
> + rpc->pktline_state = RPC_PKTLINE_END_OF_PACKET;
> + }
> + break;
> + }
> + }
> +#undef READ_ONE_HEX
> +}
> +
> static size_t rpc_in(char *ptr, size_t eltsize,
> size_t nmemb, void *buffer_)
> {
> size_t size = eltsize * nmemb;
> struct rpc_state *rpc = buffer_;
> + update_pktline_state(rpc, ptr, size);
> write_or_die(rpc->in, ptr, size);
> return size;
> }
> @@ -659,6 +737,8 @@ static int post_rpc(struct rpc_state *rpc)
> curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, rpc_in);
> curl_easy_setopt(slot->curl, CURLOPT_FILE, rpc);
>
> + rpc->pktline_state = RPC_PKTLINE_INITIAL;
> +
> err = run_slot(slot, NULL);
> if (err == HTTP_REAUTH && !large_request) {
> credential_fill(&http_auth);
> @@ -667,6 +747,11 @@ static int post_rpc(struct rpc_state *rpc)
> if (err != HTTP_OK)
> err = -1;
>
> + if (rpc->pktline_state != RPC_PKTLINE_FLUSH) {
> + error("invalid or truncated response from http server");
> + err = -1;
> + }
> +
> curl_slist_free_all(headers);
> free(gzip_body);
> return err;
^ permalink raw reply
* Re: [PATCH -next] PCI: dra7xx: Add missing of_node_put() in dra7xx_pcie_init_irq_domain()
From: Bjorn Helgaas @ 2016-11-14 21:19 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Wei Yongjun, Bjorn Helgaas, Wei Yongjun, linux-omap, linux-pci,
Shawn Lin, Heiko Stuebner, michal.simek, soren.brinkmann,
bharat.kumar.gogada, robh, Frank Rowand, devicetree
In-Reply-To: <1d95b915-ddc0-b48f-270b-fffb60ecfe5e@ti.com>
[+cc Shawn, Heiko, Michal, Soren, Bharat, Rob H, Frank, devicetree@vger]
On Sat, Nov 12, 2016 at 12:39:01PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Saturday 12 November 2016 03:08 AM, Bjorn Helgaas wrote:
> > On Mon, Oct 17, 2016 at 02:54:37PM +0000, Wei Yongjun wrote:
> >> From: Wei Yongjun <weiyongjun1@huawei.com>
> >>
> >> This node pointer is returned by of_get_next_child() with refcount
> >> incremented in this function. of_node_put() on it before exitting
> >> this function on error.
> >>
> >> This is detected by Coccinelle semantic patch.
> >>
> >> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> >
> > Kishon, this looks correct to me, so I applied it to pci/host-dra7xx for
> > v4.10. Let me know if you have any issue with it.
> >
> >> ---
> >> drivers/pci/host/pci-dra7xx.c | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
> >> index 9595fad..79297e9 100644
> >> --- a/drivers/pci/host/pci-dra7xx.c
> >> +++ b/drivers/pci/host/pci-dra7xx.c
> >> @@ -177,6 +177,7 @@ static int dra7xx_pcie_init_irq_domain(struct pcie_port *pp)
> >> &intx_domain_ops, pp);
> >> if (!pp->irq_domain) {
> >> dev_err(dev, "Failed to get a INTx IRQ domain\n");
> >> + of_node_put(pcie_intc_node);
>
> I think of_node_put should be used for both the error case and non-error case.
Hmm, OK. I don't know what the rules are. Certainly if we made these
drivers modular, I don't think we'd want to leak these references
every time we unload/reload the module. Should we do the put
immediately here, or in the module remove path, or ...?
Adding other driver and DT folks for comment.
I dropped these patches for now (dra7xx, rockchip, xilinx-nwl,
xilinx).
^ permalink raw reply
* Re: [PATCH -next] PCI: dra7xx: Add missing of_node_put() in dra7xx_pcie_init_irq_domain()
From: Bjorn Helgaas @ 2016-11-14 21:19 UTC (permalink / raw)
To: Kishon Vijay Abraham I
Cc: Wei Yongjun, Bjorn Helgaas, Wei Yongjun,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-pci-u79uwXL29TY76Z2rM5mHXA, Shawn Lin, Heiko Stuebner,
michal.simek-gjFFaj9aHVfQT0dZR+AlfA,
soren.brinkmann-gjFFaj9aHVfQT0dZR+AlfA,
bharat.kumar.gogada-gjFFaj9aHVfQT0dZR+AlfA,
robh-DgEjT+Ai2ygdnm+yROfE0A, Frank Rowand,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1d95b915-ddc0-b48f-270b-fffb60ecfe5e-l0cyMroinI0@public.gmane.org>
[+cc Shawn, Heiko, Michal, Soren, Bharat, Rob H, Frank, devicetree@vger]
On Sat, Nov 12, 2016 at 12:39:01PM +0530, Kishon Vijay Abraham I wrote:
> Hi,
>
> On Saturday 12 November 2016 03:08 AM, Bjorn Helgaas wrote:
> > On Mon, Oct 17, 2016 at 02:54:37PM +0000, Wei Yongjun wrote:
> >> From: Wei Yongjun <weiyongjun1-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> >>
> >> This node pointer is returned by of_get_next_child() with refcount
> >> incremented in this function. of_node_put() on it before exitting
> >> this function on error.
> >>
> >> This is detected by Coccinelle semantic patch.
> >>
> >> Signed-off-by: Wei Yongjun <weiyongjun1-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> >
> > Kishon, this looks correct to me, so I applied it to pci/host-dra7xx for
> > v4.10. Let me know if you have any issue with it.
> >
> >> ---
> >> drivers/pci/host/pci-dra7xx.c | 1 +
> >> 1 file changed, 1 insertion(+)
> >>
> >> diff --git a/drivers/pci/host/pci-dra7xx.c b/drivers/pci/host/pci-dra7xx.c
> >> index 9595fad..79297e9 100644
> >> --- a/drivers/pci/host/pci-dra7xx.c
> >> +++ b/drivers/pci/host/pci-dra7xx.c
> >> @@ -177,6 +177,7 @@ static int dra7xx_pcie_init_irq_domain(struct pcie_port *pp)
> >> &intx_domain_ops, pp);
> >> if (!pp->irq_domain) {
> >> dev_err(dev, "Failed to get a INTx IRQ domain\n");
> >> + of_node_put(pcie_intc_node);
>
> I think of_node_put should be used for both the error case and non-error case.
Hmm, OK. I don't know what the rules are. Certainly if we made these
drivers modular, I don't think we'd want to leak these references
every time we unload/reload the module. Should we do the put
immediately here, or in the module remove path, or ...?
Adding other driver and DT folks for comment.
I dropped these patches for now (dra7xx, rockchip, xilinx-nwl,
xilinx).
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH kvm-unit-tests v2 00/17] VT-d unit test
From: Peter Xu @ 2016-11-14 21:19 UTC (permalink / raw)
To: Andrew Jones; +Cc: kvm, rkrcmar, agordeev, jan.kiszka, pbonzini
In-Reply-To: <20161110202547.me7pcesarlkbzg6k@hawk.localdomain>
On Thu, Nov 10, 2016 at 09:25:47PM +0100, Andrew Jones wrote:
> On Wed, Nov 09, 2016 at 10:10:07AM -0500, Peter Xu wrote:
> [...]
> > Peter Xu (17):
> > x86/asm: add cpu_relax()
> > libcflat: introduce is_power_of_2()
> > x86: intel-iommu: add vt-d init test
> > libcflat: add IS_ALIGNED() macro, and page sizes
> > libcflat: moving MIN/MAX here
> > vm/page: provide PGDIR_OFFSET() macro
> > pci: introduce struct pci_dev
> > pci: provide pci_scan_bars()
> > x86/vmexit: leverage pci_scan_bars()
> > pci: provide pci_cmd_set_clr()
> > pci: provide pci_enable_defaults()
> > pci: add bdf helpers
> > pci: edu: introduce pci-edu helpers
> > x86: intel-iommu: add dmar test
> > pci: add msi support for 32/64bit address
> > x86: intel-iommu: add IR MSI test
> > x86/unittests: add intel-iommu test
>
> I think you can squash some of these patches together
> 03+17
> 08+09
> 10+11
> 12+14
These all looks sane. Will apply in the next post.
Thanks,
-- peterx
^ permalink raw reply
* Re: [PATCH -next] powernv: cpufreq: Fix uninitialized lpstate_idx in gpstates_timer_handler
From: Rafael J. Wysocki @ 2016-11-14 21:18 UTC (permalink / raw)
To: Akshay Adiga; +Cc: viresh.kumar, linux-pm, linux-kernel, linuxppc-dev, ego
In-Reply-To: <1479124767-20165-1-git-send-email-akshay.adiga@linux.vnet.ibm.com>
On Monday, November 14, 2016 05:29:27 PM Akshay Adiga wrote:
> lpstate_idx remains uninitialized in the case when elapsed_time
> is greater than MAX_RAMP_DOWN_TIME. At the end of rampdown
> global pstate should be equal to local pstate.
>
> Fixes: 20b15b766354 ("cpufreq: powernv: Use PMCR to verify global and
> localpstate")
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Akshay Adiga <akshay.adiga@linux.vnet.ibm.com>
> ---
> drivers/cpufreq/powernv-cpufreq.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c
> index c82304b..c5c5bc3 100644
> --- a/drivers/cpufreq/powernv-cpufreq.c
> +++ b/drivers/cpufreq/powernv-cpufreq.c
> @@ -624,6 +624,7 @@ void gpstate_timer_handler(unsigned long data)
>
> if (gpstates->elapsed_time > MAX_RAMP_DOWN_TIME) {
> gpstate_idx = pstate_to_idx(freq_data.pstate_id);
> + lpstate_idx = gpstate_idx;
> reset_gpstates(policy);
> gpstates->highest_lpstate_idx = gpstate_idx;
> } else {
>
Applied.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH kvm-unit-tests v2 08/17] pci: provide pci_scan_bars()
From: Andrew Jones @ 2016-11-14 21:18 UTC (permalink / raw)
To: Peter Xu; +Cc: kvm, rkrcmar, agordeev, jan.kiszka, pbonzini
In-Reply-To: <20161114203322.GD3125@pxdev.xzpeter.org>
On Mon, Nov 14, 2016 at 03:33:22PM -0500, Peter Xu wrote:
> On Thu, Nov 10, 2016 at 08:24:19PM +0100, Andrew Jones wrote:
>
> [...]
>
> > > +void pci_scan_bars(struct pci_dev *dev)
> > > +{
> > > + int i = 0;
> > > +
> > > + for (i = 0; i < PCI_BAR_NUM; i++) {
> > > + if (!pci_bar_is_valid(dev, i))
> > > + continue;
> > > + dev->bar[i] = pci_bar_get_addr(dev, i);
> >
> > What happens when you get_addr a 64-bit bar in the middle?
> > Shouldn't we skip that?
>
> Hmm yes... Do you like this?
>
> ---------8<----------
>
> diff --git a/lib/pci.c b/lib/pci.c
> index 0593699..2a58b30 100644
> --- a/lib/pci.c
> +++ b/lib/pci.c
> @@ -230,11 +230,15 @@ void pci_print(void)
>
> void pci_scan_bars(struct pci_dev *dev)
> {
> - int i = 0;
> + int i;
> +
> + memset(&dev->bar[0], 0, sizeof(dev->bar));
I'm not sure what this memset is for. Anyway, if you need to zero a
bar, why not just
bar = (phys_addr_t)0;
>
> for (i = 0; i < PCI_BAR_NUM; i++) {
> if (!pci_bar_is_valid(dev, i))
> continue;
> dev->bar[i] = pci_bar_get_addr(dev, i);
> + if (pci_bar_is64(dev, i))
> + i++;
> }
yes, this is consistent with how Alex did it in pci_probe. So
looks good to me.
> }
>
> --------->8----------
>
> pci_bar_is64() is called twice per bar, but I think it's okay here
> since it's during init and the whole scan is called only once for 6
> bars.
yeah, the "inefficiency" is no biggy.
Thanks,
drew
^ permalink raw reply
* Re: [PATCH] net/phy/vitesse: Configure RGMII skew on VSC8601, if needed
From: David Miller @ 2016-11-14 21:18 UTC (permalink / raw)
To: alex.g; +Cc: f.fainelli, gokhan, netdev, linux-kernel
In-Reply-To: <1478993533-1936-1-git-send-email-alex.g@adaptrum.com>
From: Alexandru Gagniuc <alex.g@adaptrum.com>
Date: Sat, 12 Nov 2016 15:32:13 -0800
> + if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
> + ret = vsc8601_add_skew(phydev);
I think you should use phy_interface_is_rgmii() here.
^ permalink raw reply
* [U-Boot] [PATCH RESEND 6/9] eeprom: Add DS2431 support
From: Simon Glass @ 2016-11-14 21:17 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20161114210901.ezaajyhnuehlfkhr@lukather>
Hi Maxime,
On 14 November 2016 at 14:09, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Mon, Nov 14, 2016 at 01:44:42PM -0700, Simon Glass wrote:
>> Hi Maxime,
>>
>> On 14 November 2016 at 13:12, Maxime Ripard
>> <maxime.ripard@free-electrons.com> wrote:
>> > On Mon, Nov 14, 2016 at 10:14:57AM -0500, Tom Rini wrote:
>> >> On Mon, Nov 14, 2016 at 02:42:59PM +0100, Maxime Ripard wrote:
>> >> > Hi,
>> >> >
>> >> > On Fri, Nov 11, 2016 at 11:16:39AM -0800, Moritz Fischer wrote:
>> >> > > > +U_BOOT_DRIVER(ds2431) = {
>> >> > > > + .name = "ds2431",
>> >> > > > + .id = UCLASS_EEPROM,
>> >> > > > + .ops = &ds2431_ops,
>> >> > >
>> >> > > Do you want to add a .flags = DM_UC_FLAG_SEQ_ALIAS here?
>> >> >
>> >> > I don't know. I was kind of wondering why U-Boot relies on aliases so
>> >> > much, especially when the Linux DT maintainers are saying that aliases
>> >> > should be avoided entirely, and we'll won't be able to upstream those
>> >> > changes.
>> >>
>> >> Bah. Do you have a pointer to some discussion about this handy?
>> >
>> > Rob said this multiple times, but here is an example:
>> > http://lkml.iu.edu/hypermail/linux/kernel/1609.1/00653.html
>>
>> Well that's not really an explanation!
>
> Don't shoot the messenger :)
>
> I think I found some other discussion where they discuss it at length:
> https://patchwork.kernel.org/patch/9133903/
>
> The interesting part is when Rob Herring is involved.
Oh dear. That sounds like a change to me. I'm going to leave this one to Tom :-)
Regards,
Simon
^ permalink raw reply
* [PATCH 2/2] ASoC: rt5677: Remove superfluous linux/kthread.h inclusion
From: Takashi Iwai @ 2016-11-14 21:17 UTC (permalink / raw)
To: Mark Brown; +Cc: Oder Chiou, Bard Liao, alsa-devel
In-Reply-To: <20161114211745.21761-1-tiwai@suse.de>
It's nowhere used in this driver code.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
sound/soc/codecs/rt5677-spi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/sound/soc/codecs/rt5677-spi.c b/sound/soc/codecs/rt5677-spi.c
index 91879ea95415..ebd0f7c5ad3b 100644
--- a/sound/soc/codecs/rt5677-spi.c
+++ b/sound/soc/codecs/rt5677-spi.c
@@ -20,7 +20,6 @@
#include <linux/slab.h>
#include <linux/gpio.h>
#include <linux/sched.h>
-#include <linux/kthread.h>
#include <linux/uaccess.h>
#include <linux/miscdevice.h>
#include <linux/regulator/consumer.h>
--
2.10.2
^ permalink raw reply related
* [PATCH 1/2] ASoC: rt5514: Remove superfluous linux/kthread.h inclusion
From: Takashi Iwai @ 2016-11-14 21:17 UTC (permalink / raw)
To: Mark Brown; +Cc: Oder Chiou, Bard Liao, alsa-devel
It's nowhere used in this driver code.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
sound/soc/codecs/rt5514-spi.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/sound/soc/codecs/rt5514-spi.c b/sound/soc/codecs/rt5514-spi.c
index 09103aab0cb2..0901e25d6db6 100644
--- a/sound/soc/codecs/rt5514-spi.c
+++ b/sound/soc/codecs/rt5514-spi.c
@@ -20,7 +20,6 @@
#include <linux/slab.h>
#include <linux/gpio.h>
#include <linux/sched.h>
-#include <linux/kthread.h>
#include <linux/uaccess.h>
#include <linux/miscdevice.h>
#include <linux/regulator/consumer.h>
--
2.10.2
^ permalink raw reply related
* Re: [PATCH v3] dts: omap5: board-common: fix wrong SMPS6 (VDD-DDR3) voltage
From: Tony Lindgren @ 2016-11-14 21:17 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Benoît Cousson, Rob Herring, Mark Rutland, Russell King,
linux-omap, devicetree, linux-kernel, kernel
In-Reply-To: <9718ff02c1c863e97bf1247009db8292fcff7d8d.1479124514.git.hns@goldelico.com>
* H. Nikolaus Schaller <hns@goldelico.com> [161114 03:55]:
> DDR3L is usually specified as
>
> JEDEC standard 1.35V(1.28V~1.45V) & 1.5V(1.425V~1.575V)
>
> Therefore setting smps6 regulator to 1.2V is definitively below
> minimum. It appears that real world chips are more forgiving than
> data sheets indicate, but let's set the regulator right.
>
> Note: a board that uses other voltages (DDR with 1.5V) can
> overwrite by referencing &smps6_reg.
Applying into omap-for-v4.9/fixes thanks.
Tony
^ permalink raw reply
* Re: [PATCH] cpufreq/CPPC: Add MODULE_DEVICE_TABLE for cppc_cpufreq driver
From: Prakash, Prashanth @ 2016-11-14 21:16 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: linux-pm, Hoan Tran, Christopher Covington, Al Stone
In-Reply-To: <3532123.n0qt8sN7td@vostro.rjw.lan>
On 11/13/2016 5:21 PM, Rafael J. Wysocki wrote:
> On Friday, October 14, 2016 12:00:23 PM Prashanth Prakash wrote:
>> MODULE_DEVICE_TABLE is added so that CPPC cpufreq module can be
>> automatically loaded when we have a acpi processor device with
>> "ACPI0007" hid.
>>
>> Signed-off-by: Prashanth Prakash <pprakash@codeaurora.org>
>> ---
>> drivers/cpufreq/cppc_cpufreq.c | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
>> index 4852d9e..e82bb3c 100644
>> --- a/drivers/cpufreq/cppc_cpufreq.c
>> +++ b/drivers/cpufreq/cppc_cpufreq.c
>> @@ -247,3 +247,10 @@ MODULE_DESCRIPTION("CPUFreq driver based on the ACPI CPPC v5.0+ spec");
>> MODULE_LICENSE("GPL");
>>
>> late_initcall(cppc_cpufreq_init);
>> +
>> +static const struct acpi_device_id cppc_acpi_ids[] = {
>> + {ACPI_PROCESSOR_DEVICE_HID, },
>> + {}
>> +};
>> +
>> +MODULE_DEVICE_TABLE(acpi, cppc_acpi_ids);
> Applied.
Thanks Rafael!
^ permalink raw reply
* ✗ Fi.CI.BAT: warning for series starting with [CI,01/10] drm/i915: Give each sw_fence its own lockclass
From: Patchwork @ 2016-11-14 21:16 UTC (permalink / raw)
To: Chris Wilson; +Cc: intel-gfx
In-Reply-To: <20161114204105.29171-1-chris@chris-wilson.co.uk>
== Series Details ==
Series: series starting with [CI,01/10] drm/i915: Give each sw_fence its own lockclass
URL : https://patchwork.freedesktop.org/series/15303/
State : warning
== Summary ==
Series 15303v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/15303/revisions/1/mbox/
Test drv_module_reload_basic:
pass -> DMESG-WARN (fi-skl-6770hq)
fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15
fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28
fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28
fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32
fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20
fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20
fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53
fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22
fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22
fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22
fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14
fi-skl-6700hq total:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21
fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21
fi-skl-6770hq total:244 pass:229 dwarn:1 dfail:0 fail:0 skip:14
fi-snb-2520m total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32
fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33
1ff093811f7fdf9b63a9fac336269f2083f1b433 drm-intel-nightly: 2016y-11m-14d-18h-30m-41s UTC integration manifest
43d7bf2 drm/i915/scheduler: Boost priorities for flips
fad7db5 drm/i915: Store the execution priority on the context
18c62cb drm/i915/scheduler: Execute requests in order of priorities
0239870 drm/i915/scheduler: Record all dependencies upon request construction
b960818 drm/i915/scheduler: Signal the arrival of a new request
ba8b842 drm/i915: Remove engine->execlist_lock
bfc599f drm/i915: Defer transfer onto execution timeline to actual hw submission
3c07427 drm/i915: Split request submit/execute phase into two
0468d41 drm/i915: Create distinct lockclasses for execution vs user timelines
01db6b2 drm/i915: Give each sw_fence its own lockclass
== Logs ==
For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2989/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH v1] fs: Constify path_is_under()'s arguments
From: Mickaël Salaün @ 2016-11-14 21:14 UTC (permalink / raw)
To: linux-kernel
Cc: Mickaël Salaün, Alexander Viro, Alexei Starovoitov,
Andy Lutomirski, Daniel Borkmann, Kees Cook, linux-fsdevel
The function path_is_under() doesn't modify the paths pointed by its
arguments but only browse them. Constifying this pointers make a cleaner
interface to be used by (future) code which may only have access to
const struct path pointers (e.g. LSM hooks).
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
---
fs/namespace.c | 2 +-
include/linux/fs.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/namespace.c b/fs/namespace.c
index e6c234b1a645..4d80a5066a1f 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -2997,7 +2997,7 @@ bool is_path_reachable(struct mount *mnt, struct dentry *dentry,
return &mnt->mnt == root->mnt && is_subdir(dentry, root->dentry);
}
-bool path_is_under(struct path *path1, struct path *path2)
+bool path_is_under(const struct path *path1, const struct path *path2)
{
bool res;
read_seqlock_excl(&mount_lock);
diff --git a/include/linux/fs.h b/include/linux/fs.h
index dc0478c07b2a..f96501b51c49 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2709,7 +2709,7 @@ extern struct file * open_exec(const char *);
/* fs/dcache.c -- generic fs support functions */
extern bool is_subdir(struct dentry *, struct dentry *);
-extern bool path_is_under(struct path *, struct path *);
+extern bool path_is_under(const struct path *, const struct path *);
extern char *file_path(struct file *, char *, int);
--
2.10.2
^ permalink raw reply related
* [U-Boot] [PATCH V2] Add support of ls1021a-iot
From: york sun @ 2016-11-14 21:13 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1478153717-4586-1-git-send-email-feng.li_2@nxp.com>
On 11/02/2016 11:23 PM, feng.li_2 at nxp.com wrote:
> From: Feng Li <feng.li_2@nxp.com>
>
> The patch add support ls1021a-iot.
> It supports I2C, MMC, PCIe, eTSEC, SATA,
> EEPROM, CPLD, HDMI, Serial port, HXCI,
> DSPI, SD boot, QSPI boot, Broadcom wifi
> card, QCA wifi card.
You wrapped too short. You already have a README file describing what is
supported. I don't think it is necessary to put in the commit message. I
will change it to "The patch adds support for Freescale ls1021a-iot
board.". If you don't repin this patch for other reason, no action is
needed from you.
>
> Signed-off-by: Feng Li <feng.li_2@nxp.com>
> Cc: York Sun <york.sun@nxp.com>
> Cc: Alison Wang <alison.wang@nxp.com>
> ---
> Changes for V2:
> - CPU_V7_HAS_NONSEC and CPU_V7_HAS_VIRT are moved to Kconfig
> to correctly select ARMV7_PSCI.
> - CONFIG_ARMV7_PSCI_1_0 and CONFIG_ARMV7_PSCI_GTE_1_0 are
> deleted.
>
> arch/arm/Kconfig | 15 +
> arch/arm/dts/Makefile | 3 +-
> arch/arm/dts/ls1021a-iot-duart.dts | 16 ++
> arch/arm/dts/ls1021a-iot.dtsi | 103 +++++++
> board/freescale/ls1021aiot/Kconfig | 15 +
> board/freescale/ls1021aiot/MAINTAINERS | 7 +
> board/freescale/ls1021aiot/Makefile | 9 +
> board/freescale/ls1021aiot/README | 58 ++++
> board/freescale/ls1021aiot/dcu.c | 47 ++++
> board/freescale/ls1021aiot/ls1021aiot.c | 259 +++++++++++++++++
> board/freescale/ls1021aiot/ls102xa_pbi.cfg | 14 +
> board/freescale/ls1021aiot/ls102xa_rcw_sd.cfg | 27 ++
> board/freescale/ls1021aiot/psci.S | 28 ++
> configs/ls1021aiot_qspi_defconfig | 15 +
> configs/ls1021aiot_sdcard_defconfig | 17 ++
> include/configs/ls1021aiot.h | 367 +++++++++++++++++++++++++
> 16 files changed, 999 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/dts/ls1021a-iot-duart.dts
> create mode 100644 arch/arm/dts/ls1021a-iot.dtsi
> create mode 100644 board/freescale/ls1021aiot/Kconfig
> create mode 100644 board/freescale/ls1021aiot/MAINTAINERS
> create mode 100644 board/freescale/ls1021aiot/Makefile
> create mode 100644 board/freescale/ls1021aiot/README
> create mode 100644 board/freescale/ls1021aiot/dcu.c
> create mode 100644 board/freescale/ls1021aiot/ls1021aiot.c
> create mode 100644 board/freescale/ls1021aiot/ls102xa_pbi.cfg
> create mode 100644 board/freescale/ls1021aiot/ls102xa_rcw_sd.cfg
> create mode 100644 board/freescale/ls1021aiot/psci.S
> create mode 100644 configs/ls1021aiot_qspi_defconfig
> create mode 100644 configs/ls1021aiot_sdcard_defconfig
> create mode 100644 include/configs/ls1021aiot.h
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index d7a9b11..5a46ad4 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -761,6 +761,20 @@ config TARGET_LS1021ATWR
> select ARCH_SUPPORT_PSCI
> select LS1_DEEP_SLEEP
>
> +config TARGET_LS1021AIOT
You should use a space instead of a tab here. It causes a false alarm
when compiling. I will fix this when merging. No action is needed from you.
York
^ permalink raw reply
* [Buildroot] [PATCH] dtv-scan-tables: rename file to have only ASCII characters
From: Thomas Petazzoni @ 2016-11-14 21:12 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20161114211024.GC3399@free.fr>
Hello,
On Mon, 14 Nov 2016 22:10:24 +0100, Yann E. MORIN wrote:
> At first, I was not very happy about this, because the filename is also
> displayed to the user, so it would make sense to keep localised names.
>
> However, you are right that there is no standard way to encode
> filenames, so this is not very reliable to depend on the filename to
> provide a user-visible representation of the city/country/... Instead,
> the location should be encoded in the file itself, possibly using the
> filename as a ascii-only fallback.
There are already many many other files that should have non-ASCII
characters to accurately represent the name of the city or region, but
that don't have them. From the commit log of the patch I just sent
upstream:
- pl-Wroclaw should be written pl-Wroc?aw
- se-Laxsjo should be written se-Laxsj?
- de-Dusseldorf should be written de-D?sseldorf
- vn-Thaibinh should be written vn-Th?i_B?nh
> > + mv $(TARGET_DIR)/usr/share/dvb/dvb-t/pl-Krosno_Sucha* \
> > + $(TARGET_DIR)/usr/share/dvb/dvb-t/pl-Krosno_Sucha_Gora
>
> Can't you do that in a post-extrat or post-patch hook?
Sure, v2 coming.
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.