[PATCH] net: cavium: liquidio: Use vzalloc instead of vmalloc
vzalloc combines vmalloc and memset 0.
The Coccinelle semantic patch used to make this change is as follows:
@@
type T;
T *d;
expression e;
statement S;
@@
d =
-vmalloc
+vzalloc
(...);
if (!d) S
- memset(d, 0, sizeof(T));
Signed-off-by: Amitoj Kaur Chawla
---
drivers/net/ethernet/cavium/liquidio/octeon_device.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/cavium/liquidio/octeon_device.c
b/drivers/net/ethernet/cavium/liquidio/octeon_device.c
index f67641a..2bf90c1 100644
--- a/drivers/net/ethernet/cavium/liquidio/octeon_device.c
+++ b/drivers/net/ethernet/cavium/liquidio/octeon_device.c
@@ -759,13 +759,10 @@ int octeon_setup_instr_queues(struct octeon_device *oct)
for (i = 0; i < num_iqs; i++) {
oct->instr_queue[i] =
- vmalloc(sizeof(struct octeon_instr_queue));
+ vzalloc(sizeof(struct octeon_instr_queue));
if (!oct->instr_queue[i])
return 1;
- memset(oct->instr_queue[i], 0,
- sizeof(struct octeon_instr_queue));
-
oct->instr_queue[i]->app_ctx = (void *)(size_t)i;
if (octeon_init_instr_queue(oct, i, num_descs))
return 1;
@@ -795,12 +792,10 @@ int octeon_setup_output_queues(struct octeon_device *oct)
oct->num_oqs = 0;
for (i = 0; i < num_oqs; i++) {
- oct->droq[i] = vmalloc(sizeof(*oct->droq[i]));
+ oct->droq[i] = vzalloc(sizeof(*oct->droq[i]));
if (!oct->droq[i])
return 1;
- memset(oct->droq[i], 0, sizeof(struct octeon_droq));
-
if (octeon_init_droq(oct, i, num_descs, desc_size, NULL))
return 1;
--
1.9.1
[PATCH] ACPICA: Use acpi_os_allocate_zeroed
acpi_os_allocate_zeroed combines acpi_os_allocate and memset 0.
The Coccinelle semantic patch used to make this change is as follows:
@@
type T;
T *d;
expression e;
statement S;
@@
d =
-acpi_os_allocate
+acpi_os_allocate_zeroed
(...);
if (!d) S
- memset(d, 0, sizeof(T));
Signed-off-by: Amitoj Kaur Chawla
---
drivers/acpi/acpica/uttrack.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/acpi/acpica/uttrack.c b/drivers/acpi/acpica/uttrack.c
index 60c406a..5ad2641 100644
--- a/drivers/acpi/acpica/uttrack.c
+++ b/drivers/acpi/acpica/uttrack.c
@@ -95,13 +95,11 @@ acpi_ut_create_list(char *list_name,
{
struct acpi_memory_list *cache;
- cache = acpi_os_allocate(sizeof(struct acpi_memory_list));
+ cache = acpi_os_allocate_zeroed(sizeof(struct acpi_memory_list));
if (!cache) {
return (AE_NO_MEMORY);
}
- memset(cache, 0, sizeof(struct acpi_memory_list));
-
cache->list_name = list_name;
cache->object_size = object_size;
--
1.9.1
Re: [PATCH net-next] net: ena: Add a driver for Amazon Elastic Network Adapters (ENA)
On Thu, Jun 16, 2016 at 07:06:52PM +0100, Ben Hutchings wrote:
> On Thu, 2016-06-16 at 10:55 -0700, Benjamin Poirier wrote:
> > On 2016/06/13 11:46, Netanel Belgazal wrote:
> [...]
> > > +static ssize_t ena_show_small_copy_len(struct device *dev,
> > > + struct device_attribute *attr, char *buf)
> > > +{
> > > + struct ena_adapter *adapter = dev_get_drvdata(dev);
> > > +
> > > + return sprintf(buf, "%d\n", adapter->small_copy_len);
> > > +}
> > > +
> > > +static DEVICE_ATTR(small_copy_len, S_IRUGO | S_IWUSR,
> > > ena_show_small_copy_len,
> > > + ena_store_small_copy_len);
> >
> > This is what many other drivers call (rx_)copybreak. Perhaps it's time
> > to add it to ethtool as well?
> [...]
>
> There is the 'tunable' ethtool API for random parameters like
> rx_copybreak. The ethtool utility doesn't support it yet, though.
So I started implementing proper support for this in ethtool in a
generic way (retrieving the string set, parsing generically, etc), but
it seems that the implementation isn't quite as complete as one would
like. You said [1] that the kernel returns the type of each tunable,
but I don't see this implemented anywhere.
The string set also includes "Unspec", which is of dubious value.
I think that something tunable specific is going to need to be added
apart from ETHTOOL_GSTRINGS to provide ethtool the needed type
information.
--msw
[1] http://thread.gmane.org/gmane.linux.network/367058/focus=376701
Re: [PATCH] sparc64: Swap registers for fault code and address in mna trap
From: 神田 尚 Date: Fri, 17 Jun 2016 01:49:11 + > This bug may occur in the following. > > user_rtt_fill_64bit <= If mna trap occurred, call do_mna > +-> do_mna <= Mistake storing registers for fault code and > address > +-> winfix_mna > +-> user_rtt_fill_fixup <= Put fault address into > thread_info->flag's TI_FAULT_CODE > +-> do_sparc64_fault() <= If fault address has FAULT_CODE_ITLB > and FAULT_CODE_DTLB bits, call BUG() > +-> BUG() We should not be invoking do_sparc64_fault() in this case. Instead, we call either sun4v_do_mna() or mem_address_unaligned(). Neither of which care about the values stored in the thread's fault address and code. If you can really trigger this code path, please post the kernel log backtrace that happens when the BUG() triggers. That way we can figure out what the real problem is. Your patch is also wrong for other reasons, it would break the unaligned trap code paths that don't go via user_rtt_fill_64bit fixups.
Re: [PATCH v2 4/8] scripts: add glimpse.sh for indexing the kernel
On Sat, 18 Jun 2016, Luis R. Rodriguez wrote: > On Fri, Jun 17, 2016 at 05:35:26PM +0200, Julia Lawall wrote: > > On Fri, 17 Jun 2016, Luis R. Rodriguez wrote: > > > > > On Fri, Jun 17, 2016 at 11:44:26AM +0200, Julia Lawall wrote: > > > > I'm not sure that this is worth it. It adds a dependency on a tool that > > > > seems not to be well maintained. In terms of Coccinelle, I'm not sure > > > > that it gives a big benefit. > > > > > > > > Attached is a graph showing the file selection time for Coccinelle for a > > > > selection of fairly complex semantic patches. Coccigrep is just a > > > > line-by-line regexp search implemented in ocaml, gitgrep uses git grep. > > > > In most cases, glimpse is clearly faster. > > > > > > > > On the other hand, it seems that glimpse often selects more files. > > > > Sometimes a few more, eg 16 vs 14, and sometimes quite a lot more, eg > > > > 538 > > > > vs 236. I suspect that this is because glimpse considers _ to be a > > > > space, > > > > and thus it can have many false positives. There are, however, a few > > > > cases where glimpse also selects fewer files. > > > > > > > > The file processing time (ie parsing the file, searching for, matches of > > > > the semantic patch in the file, and performing the transformation) is > > > > normally much higher than the file selection time. > > > > > > > > So it seems that git grep is currently a better option for the kernel. > > > > > > Great, thanks, consider this patch dropped, do we want the heuristics > > > for the cache index in place though or should I drop that as well ? > > > > I assume you mean this patch: > > > > [PATCH v2 3/8] coccicheck: add indexing enhancement options > > > > I think it should be dropped. It adds complexity and git grep works > > pretty well. > > Hmm but coccicheck does not make use of --git-grep even. > > > If people want to use something else, they can use SPARGS, > > or a .cocciconfig file, eg: > > > > [spatch] > > options = --use-glimpse > > Neat will these be used last and thus override anything? Good point. If it is in the home directory, it is overrided by everything. So make coccicheck shouldn't have an option related to this issue. > If so, what > about just adding an upstream .cocciconfig with --use-gitgrep -- only > issue then is what if a user wants to use idutils ? How do we let them > override? If we have an upstream .cocciconfig with --use-gitgrep, then the user can specify an SPARGS with --use-idutils and override. If we are making an upstream .cocciconfig, I would put a timeout in it too. In my experience, 120 (seconds) is fine. Maybe 200 to give a little more margin. Again, this can be overridden on the command line. julia
[PATCH RESEND] trace: function graph: Fix filters for function_graph threshold
Function graph tracer currently ignores filters if tracing_thresh is set.
For example, even if set_ftrace_pid is set, then its ignored if tracing_thresh
set, resulting in all processes being traced.
To fix this, we reuse the same entry function as when tracing_thresh is not
set and do everything as in the regular case except for writing the function
entry
to the ring buffer.
Cc: Frederic Weisbecker
Cc: Steven Rostedt
Cc: Ingo Molnar
Signed-off-by: Joel Fernandes
---
kernel/trace/trace_functions_graph.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/kernel/trace/trace_functions_graph.c
b/kernel/trace/trace_functions_graph.c
index a663cbb..0967fac 100644
--- a/kernel/trace/trace_functions_graph.c
+++ b/kernel/trace/trace_functions_graph.c
@@ -337,6 +337,13 @@ int trace_graph_entry(struct ftrace_graph_ent *trace)
if (ftrace_graph_notrace_addr(trace->func))
return 1;
+ /*
+* Stop here if tracing_threshold is set. We only write function return
+* events to the ring buffer.
+*/
+ if (tracing_thresh)
+ return 1;
+
local_irq_save(flags);
cpu = raw_smp_processor_id();
data = per_cpu_ptr(tr->trace_buffer.data, cpu);
@@ -354,14 +361,6 @@ int trace_graph_entry(struct ftrace_graph_ent *trace)
return ret;
}
-static int trace_graph_thresh_entry(struct ftrace_graph_ent *trace)
-{
- if (tracing_thresh)
- return 1;
- else
- return trace_graph_entry(trace);
-}
-
static void
__trace_graph_function(struct trace_array *tr,
unsigned long ip, unsigned long flags, int pc)
@@ -456,7 +455,7 @@ static int graph_trace_init(struct trace_array *tr)
set_graph_array(tr);
if (tracing_thresh)
ret = register_ftrace_graph(&trace_graph_thresh_return,
- &trace_graph_thresh_entry);
+ &trace_graph_entry);
else
ret = register_ftrace_graph(&trace_graph_return,
&trace_graph_entry);
--
2.5.0
Re: [PATCH 2/2] net: ethernet: et131x: use phy_ethtool_{get|set}_link_ksettings
From: Philippe Reynes
Date: Fri, 17 Jun 2016 23:32:15 +0200
> There are two generics functions phy_ethtool_{get|set}_link_ksettings,
> so we can use them instead of defining the same code in the driver.
>
> Signed-off-by: Philippe Reynes
Applied.
Re: [PATCH 1/2] net: ethernet: et131x: use phydev from struct net_device
From: Philippe Reynes Date: Fri, 17 Jun 2016 23:32:14 +0200 > The private structure contain a pointer to phydev, but the structure > net_device already contain such pointer. So we can remove the pointer > phydev in the private structure, and update the driver to use the > one contained in struct net_device. > > Signed-off-by: Philippe Reynes Applied.
Re: Stable -rc git trees and email headers
Hi Greg, On Fri, Jun 17, 2016 at 08:16:20PM -0700, Greg KH wrote: > Hi, > > I've finally gotten off my butt and made my quilt trees of patches into > a "semi-proper" git tree to make it easier for people to test them. > > I'm now pushing the patches I accept into the stable queues into the git > tree here: > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > I'll push them out in chunks, as I accept them, and when I do a "real" > -rc release. Right now the HEAD of each branch will have a -rc1 tag on > them, just because it makes it a bit easier on my end. Do you mean you'll tag them when you issue a review ? If so, maybe that can help our testers automatically trigger a series of tests when they spot a tag that was not tested yet instead of having to monitor emails ? If that's the case, I have no issue with pushing a tag when I emit a series as well. Cheers, Willy
Re: [PATCH] net: tilegx: use correct timespec64 type
From: Arnd Bergmann
Date: Fri, 17 Jun 2016 18:15:30 +0200
> The conversion to the 64-bit time based ptp methods left two instances
> of 'struct timespec' in place. This is harmless because 64-bit
> architectures define timespec64 as timespec, and this driver is
> not used on 32-bit machines.
>
> However, using 'struct timespec64' directly is obviously the right
> thing to do, and will help us remove 'struct timespec' in the future.
>
> Signed-off-by: Arnd Bergmann
> Fixes: b9acf24f779c ("ptp: tilegx: convert to the 64 bit get/set time
> methods.")
Applied, thanks.
Re: [very-RFC 0/8] TSN driver for the kernel
Hi, Sorry to be late. In this weekday, I have little time for this thread because working for alsa-lib[1]. Besides, I'm not full-time developer for this kind of work. In short, I use my limited private time for this discussion. On Jun 15 2016 17:06, Richard Cochran wrote: > On Wed, Jun 15, 2016 at 12:15:24PM +0900, Takashi Sakamoto wrote: >>> On Mon, Jun 13, 2016 at 01:47:13PM +0200, Richard Cochran wrote: I have seen audio PLL/multiplier chips that will take, for example, a 10 kHz input and produce your 48 kHz media clock. With the right HW design, you can tell your PTP Hardware Clock to produce a 1 PPS, and you will have a synchronized AVB endpoint. The software is all there already. Somebody should tell the ALSA guys about it. >> >> Just from my curiosity, could I ask you more explanation for it in ALSA >> side? > > (Disclaimer: I really don't know too much about ALSA, expect that is > fairly big and complex ;) In this morning, I read IEEE 1722:2011 and realized that it quite roughly refers to IEC 61883-1/6 and includes much ambiguities to end applications. (In my opinion, the author just focuses on packet with timestamps, without enough considering about how to implement endpoint applications which perform semi-real sampling, fetching and queueing and so on, so as you. They're satisfied just by handling packet with timestamp, without enough consideration about actual hardware/software applications.) > Here is what I think ALSA should provide: > > - The DA and AD clocks should appear as attributes of the HW device. > > - There should be a method for measuring the DA/AD clock rate with > respect to both the system time and the PTP Hardware Clock (PHC) > time. > > - There should be a method for adjusting the DA/AD clock rate if > possible. If not, then ALSA should fall back to sample rate > conversion. > > - There should be a method to determine the time delay from the point > when the audio data are enqueued into ALSA until they pass through > the D/A converter. If this cannot be known precisely, then the > library should provide an estimate with an error bound. > > - I think some AVB use cases will need to know the time delay from A/D > until the data are available to the local application. (Distributed > microphones? I'm not too sure about that.) > > - If the DA/AD clocks are connected to other clock devices in HW, > there should be a way to find this out in SW. For example, if SW > can see the PTP-PHC-PLL-DA relationship from the above example, then > it knows how to synchronize the DA clock using the network. > > [ Implementing this point involves other subsystems beyond ALSA. It > isn't really necessary for people designing AVB systems, since > they know their designs, but it would be nice to have for writing > generic applications that can deal with any kind of HW setup. ] Depends on which subsystem decides "AVTP presentation time"[3]. This value is dominant to the number of events included in an IEC 61883-1 packet. If this TSN subsystem decides it, most of these items don't need to be in ALSA. As long as I know, the number of AVTPDU per second seems not to be fixed. So each application is not allowed to calculate the timestamp by its own way unless TSN implementation gives the information to each applications. For your information, in current ALSA implementation of IEC 61883-1/6 on IEEE 1394 bus, the presentation timestamp is decided in ALSA side. The number of isochronous packet transmitted per second is fixed by 8,000 in IEEE 1394, and the number of data blocks in an IEC 61883-1 packet is deterministic according to 'sampling transfer frequency' in IEC 61883-6 and isochronous cycle count passed from Linux FireWire subsystem. In the TSN subsystem, like FireWire subsystem, callback for filling payload should have information of 'when the packet is scheduled to be transmitted'. With the information, each application can calculate the number of event in the packet and presentation timestamp. Of cource, this timestamp should be handled as 'avtp_timestamp' in packet queueing. >> In ALSA, sampling rate conversion should be in userspace, not in kernel >> land. In alsa-lib, sampling rate conversion is implemented in shared object. >> When userspace applications start playbacking/capturing, depending on PCM >> node to access, these applications load the shared object and convert PCM >> frames from buffer in userspace to mmapped DMA-buffer, then commit them. > > The AVB use case places an additional requirement on the rate > conversion. You will need to adjust the frequency on the fly, as the > stream is playing. I would guess that ALSA doesn't have that option? In ALSA kernel/userspace interfaces , the specification cannot be supported, at all. Please explain about this requirement, where it comes from, which specification and clause describe it (802.1AS or 802.1Q?). As long as I read IEEE 1722, I cannot find
Re: Stable -rc git trees and email headers
Hi Greg, On Fri, Jun 17, 2016 at 08:16:20PM -0700, Greg KH wrote: > Hi, > > I've finally gotten off my butt and made my quilt trees of patches into > a "semi-proper" git tree to make it easier for people to test them. > > I'm now pushing the patches I accept into the stable queues into the git > tree here: > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > Fengguang, can you add these to the 0-day bot? Sure. It's great to see these early testing branches! > The branches to watch are all of the currently-active stable trees. > Right now that would be "linux-3.14.y", "linux-4.4.y", and > "linux-4.6.y". Do I need to tell you about future branches, or can > you just pick up new ones when they show up? The robot will auto pick new branches up. > And can I get announcements if/when the tests pass (or fail) so I know > all is ok? OK. Thanks, Fengguang
Re: [PATCH] mm: fix account pmd page to the process
On 2016/6/17 23:39, Mike Kravetz wrote: > On 06/17/2016 05:25 AM, Kirill A. Shutemov wrote: >> From fd22922e7b4664e83653a84331f0a95b985bff0c Mon Sep 17 00:00:00 2001 >> From: "Kirill A. Shutemov" >> Date: Fri, 17 Jun 2016 15:07:03 +0300 >> Subject: [PATCH] hugetlb: fix nr_pmds accounting with shared page tables >> >> We account HugeTLB's shared page table to all processes who share it. >> The accounting happens during huge_pmd_share(). >> >> If somebody populates pud entry under us, we should decrease pagetable's >> refcount and decrease nr_pmds of the process. >> >> By mistake, I increase nr_pmds again in this case. :-/ >> It will lead to "BUG: non-zero nr_pmds on freeing mm: 2" on process' >> exit. >> >> Let's fix this by increasing nr_pmds only when we're sure that the page >> table will be used. >> >> Signed-off-by: Kirill A. Shutemov > Nice, > Reviewed-by: Mike Kravetz > > I agree that we do not necessarily need a back port. I have not seen > reports of people experiencing this race and seeing the BUG (on mm > tear-down). > > zhongjiang, did someone actually hit the BUG? Or, did you find it by > code examination? > just code examination.
Re: [PATCH 1/2] usb: phy: Add initial support for Qualcomm HSIC PHY
Hi,
[auto build test WARNING on balbi-usb/next]
[also build test WARNING on v4.7-rc3 next-20160617]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Neil-Armstrong/usb-phy-Add-support-for-the-Qualcomm-HSIC-USB-PHY/20160617-183519
base: https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
config: m32r-allyesconfig (attached as .config)
compiler: m32r-linux-gcc (GCC) 4.9.0
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m32r
All warnings (new ones prefixed by >>):
drivers/usb/phy/phy-qcom-hsic-usb.c: In function 'ulpi_read':
>> drivers/usb/phy/phy-qcom-hsic-usb.c:106:4: warning: format '%x' expects
>> argument of type 'unsigned int', but argument 3 has type 'long unsigned int'
>> [-Wformat=]
readl(USB_ULPI_VIEWPORT));
^
vim +106 drivers/usb/phy/phy-qcom-hsic-usb.c
90 int cnt = 0;
91
92 /* initiate read operation */
93 writel(ULPI_RUN | ULPI_READ | ULPI_ADDR(reg),
94 USB_ULPI_VIEWPORT);
95
96 /* wait for completion */
97 while (cnt < ULPI_IO_TIMEOUT_USEC) {
98 if (!(readl(USB_ULPI_VIEWPORT) & ULPI_RUN))
99 break;
100 udelay(1);
101 cnt++;
102 }
103
104 if (cnt >= ULPI_IO_TIMEOUT_USEC) {
105 dev_err(phy->dev, "ulpi_read: timeout %08x\n",
> 106 readl(USB_ULPI_VIEWPORT));
107 return -ETIMEDOUT;
108 }
109 return ULPI_DATA_READ(readl(USB_ULPI_VIEWPORT));
110 }
111
112 static int ulpi_write(struct usb_phy *phy, u32 val, u32 reg)
113 {
114 struct phy_hsic *qphy = container_of(phy, struct phy_hsic, phy);
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH 0/6] eBPF JIT for PPC64
On 2016-06-13 15:40, Naveen N. Rao wrote: On 2016/06/10 10:47PM, David Miller wrote: From: "Naveen N. Rao" Date: Tue, 7 Jun 2016 19:02:17 +0530 > Please note that patch [2] is a pre-requisite for this patchset, and is > not yet upstream. ... > [1] http://thread.gmane.org/gmane.linux.kernel/2188694 > [2] http://thread.gmane.org/gmane.linux.ports.ppc.embedded/96514 Because of #2 I don't think I can take this directly into the networking tree, right? Therefore, how would you like this to be merged? Hi David, Thanks for asking. Yes, I think it is better to take this through the powerpc tree as all the changes are contained within arch/powerpc, unless Michael Ellerman feels differently. Michael? Yeah I was planning to take it. I put it in my test tree last night but it broke the build for some configs. Once that is fixed I'll take it via powerpc#next. cheers
Re: [PATCH] x86: fux duplicated X86_BUG(9) macro
On Fri, Jun 17, 2016 at 5:15 PM, Dave Hansen wrote: > > Now sending with actual stable@ address... > > -- > > From: Dave Hansen > > cpufeatures.h currently defines X86_BUG(9) twice on 32-bit: Acked-by: Andy Lutomirski # who is suitably embarrassed That being said, you or Ingo should consider fixing the typo in $SUBJECT. > > #define X86_BUG_NULL_SEGX86_BUG(9) /* Nulling a selector > preserves the base */ > ... > #ifdef CONFIG_X86_32 > #define X86_BUG_ESPFIX X86_BUG(9) /* "" IRET to 16-bit SS > corrupts ESP/RSP high bits */ > #endif > > I think what happened was that this added the X86_BUG_ESPFIX, but > in an #ifdef below most of the bugs: > > [58a5aac5] x86/entry/32: Introduce and use X86_BUG_ESPFIX instead of > paravirt_enabled > > Then this came along and added X86_BUG_NULL_SEG, but collided > with the earlier one that did the bug below the main block > defining all the X86_BUG()s. > > [7a5d6704] x86/cpu: Probe the behavior of nulling out a segment at > boot time > > Signed-off-by: Dave Hansen > Cc: Andy Lutomirski > Cc: sta...@vger.kernel.org > --- > > b/arch/x86/include/asm/cpufeatures.h |6 ++ > 1 file changed, 2 insertions(+), 4 deletions(-) > > diff -puN arch/x86/include/asm/cpufeatures.h~fix-x86-bugs-macros > arch/x86/include/asm/cpufeatures.h > --- a/arch/x86/include/asm/cpufeatures.h~fix-x86-bugs-macros2016-06-17 > 17:10:30.978602807 -0700 > +++ b/arch/x86/include/asm/cpufeatures.h2016-06-17 17:10:30.982602989 > -0700 > @@ -301,10 +301,6 @@ > #define X86_BUG_FXSAVE_LEAKX86_BUG(6) /* FXSAVE leaks FOP/FIP/FOP */ > #define X86_BUG_CLFLUSH_MONITORX86_BUG(7) /* AAI65, CLFLUSH required > before MONITOR */ > #define X86_BUG_SYSRET_SS_ATTRSX86_BUG(8) /* SYSRET doesn't fix up > SS attrs */ > -#define X86_BUG_NULL_SEG X86_BUG(9) /* Nulling a selector preserves > the base */ > -#define X86_BUG_SWAPGS_FENCE X86_BUG(10) /* SWAPGS without input dep on GS > */ > - > - > #ifdef CONFIG_X86_32 > /* > * 64-bit kernels don't use X86_BUG_ESPFIX. Make the define conditional > @@ -312,5 +308,7 @@ > */ > #define X86_BUG_ESPFIX X86_BUG(9) /* "" IRET to 16-bit SS corrupts > ESP/RSP high bits */ > #endif > +#define X86_BUG_NULL_SEG X86_BUG(10) /* Nulling a selector preserves > the base */ > +#define X86_BUG_SWAPGS_FENCE X86_BUG(11) /* SWAPGS without input dep on GS > */ > > #endif /* _ASM_X86_CPUFEATURES_H */ > _ -- Andy Lutomirski AMA Capital Management, LLC
Re: [PATCH v3 0/2] net: ethernet: ti: cpsw: delete rx_descs property
From: Ivan Khoronzhuk Date: Fri, 17 Jun 2016 13:25:38 +0300 > There is no reason in rx_descs property because davinici_cpdma > driver splits pool of descriptors equally between tx and rx channels. > So, this patch series makes driver to use available number of > descriptors for rx channels. > > Based on > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git > master > > Since v2: > - add declaration of buf_num in correct order Series applied, thanks.
Re: Stable -rc git trees and email headers
Hi Greg, On 06/17/2016 08:16 PM, Greg KH wrote: Hi, I've finally gotten off my butt and made my quilt trees of patches into a "semi-proper" git tree to make it easier for people to test them. I'm now pushing the patches I accept into the stable queues into the git tree here: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Great! I'll push them out in chunks, as I accept them, and when I do a "real" -rc release. Right now the HEAD of each branch will have a -rc1 tag on them, just because it makes it a bit easier on my end. Note these branches WILL get rebased. All the time. So don't count on them to contain anything that will stick around, UNTIL a real stable release happens. Guenter, I hope this helps with your testing, is there anything that I can do here to make it easier for you? Yes, it does. I'll see if I can switch to fetching the branches from there in the next couple of days. I'm all happy ... Thanks! Guenter
Re: [v3,1/4] mfd: cros_ec: Add cros_ec_cmd_xfer_status helper
On 06/17/2016 06:08 PM, Brian Norris wrote:
On Fri, Jun 17, 2016 at 02:41:51PM -0700, Guenter Roeck wrote:
On Fri, Jun 17, 2016 at 12:58:12PM -0700, Brian Norris wrote:
+int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
+ struct cros_ec_command *msg)
+{
+ int ret;
+
+ ret = cros_ec_cmd_xfer(ec_dev, msg);
+ if (ret < 0)
+ dev_err(ec_dev->dev, "Command xfer error (err:%d)\n", ret);
+ else if (msg->result != EC_RES_SUCCESS)
+ return -EECRESULT - msg->result;
I have been wondering about the error return codes here, and if they should be
converted to standard Linux error codes. For example, I just hit error -1003
with a driver I am working on. This translates to EC_RES_INVALID_PARAM, or,
in Linux terms, -EINVAL. I think it would be better to use standard error
codes, especially since some of the errors are logged.
How do you propose we do that? Do all of the following become EINVAL?
EC_RES_INVALID_COMMAND
EC_RES_INVALID_PARAM
EC_RES_INVALID_VERSION
EC_RES_INVALID_HEADER
Personal preference, but yes.
We lose a lot of information that way. And particularly, cros_ec_num_pwms()
won't be able to count as accurately. But I can just go back to not using this
You lost me there, sorry.
API if that's what you'd like...
That isn't what I suggested.
Guenter
Re: [PATCH] Staging: comedi: comedi_fops.c: Replaced ACCESS_ONCE with READ/WRITE_ONCE
On Sun, Jun 05, 2016 at 08:10:50PM -0700, Andy Eleftherion wrote: > Replaced ACCESS_ONCE calls with READ/WRITE_ONCE calls. Why?
Re: [PATCH 2649/2649] Staging: comedi : fixed a camel case style issue
On Wed, Jun 01, 2016 at 10:35:57AM +0100, Ian Abbott wrote:
> On 01/06/16 10:19, Ashwin Ravichandran wrote:
> > Fixed a coding style issue.
> >
> > Signed-off-by: Ashwin Ravichandran
> > ---
> > drivers/staging/comedi/drivers/addi-data/hwdrv_apci3501.c | 2 +-
> > drivers/staging/comedi/drivers/addi_apci_3501.c | 4 ++--
> > 2 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci3501.c
> > b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci3501.c
> > index 3757074..9c27999 100644
> > --- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci3501.c
> > +++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci3501.c
> > @@ -28,7 +28,7 @@ static int apci3501_config_insn_timer(struct
> > comedi_device *dev,
> > data[0] != ADDIDATA_TIMER)
> > return -EINVAL;
> >
> > - devpriv->tsk_Current = current;
> > + devpriv->tsk_current = current;
> >
> > devpriv->timer_mode = data[0];
> >
> > diff --git a/drivers/staging/comedi/drivers/addi_apci_3501.c
> > b/drivers/staging/comedi/drivers/addi_apci_3501.c
> > index 40ff914..b2f6712 100644
> > --- a/drivers/staging/comedi/drivers/addi_apci_3501.c
> > +++ b/drivers/staging/comedi/drivers/addi_apci_3501.c
> > @@ -68,7 +68,7 @@
> > struct apci3501_private {
> > unsigned long amcc;
> > unsigned long tcw;
> > - struct task_struct *tsk_Current;
> > + struct task_struct *tsk_current;
> > unsigned char timer_mode;
> > };
> >
> > @@ -273,7 +273,7 @@ static irqreturn_t apci3501_interrupt(int irq, void *d)
> > }
> >
> > /* Enable Interrupt Send a signal to from kernel to user space */
> > - send_sig(SIGIO, devpriv->tsk_Current, 0);
> > + send_sig(SIGIO, devpriv->tsk_current, 0);
> > ctrl = inl(devpriv->tcw + ADDI_TCW_CTRL_REG);
> > ctrl &= ~(ADDI_TCW_CTRL_GATE | ADDI_TCW_CTRL_TRIG |
> > ADDI_TCW_CTRL_IRQ_ENA);
> >
>
> The patch looks fine (although this odd-ball Comedi driver shouldn't really
> be sending signals to a user-space task!).
Yeah, that's really odd, fixing that would be nice...
Re: [PATCH 2649/2649] Staging: comedi : fixed a camel case style issue
On Wed, Jun 01, 2016 at 02:19:35AM -0700, Ashwin Ravichandran wrote: > Fixed a coding style issue. Which one? And where are the 2648 previous patches in this series? thanks, greg k-h
Re: [PATCH] Staging: comedi: das16.c: Added a blank line fixed a comment, coding style issue
On Tue, May 31, 2016 at 09:00:59PM -0300, Pedro Nieto wrote: > From: PedroNieto No space? > > Fixed a coding style issue. Which one? Please be specific.
Re: [PATCH] Staging: comedi: ni_atmio: fixed spacing and comment style issues
On Thu, May 26, 2016 at 06:35:48PM -0500, Steven Laabs wrote: > Fixed coding style issues. That's very vague, please be specific and exact. thanks, greg k-h
Re: [PATCH] Staging: comedi: quatech_daqp_cs.c: Fix a unsigned warning issue
On Tue, May 17, 2016 at 10:23:44PM +0530, Amit Ghadge wrote: > This is a patch to the quatech_daqp_cs.c file that fixes by using > unsigned int instead of unsigned, following warning found by checkpatch. > * WARNING: Prefer 'unsigned int' to bare use of 'unsigned' > > Signed-off-by: Amit Ghadge > Reviewed-by: Ian Abbott > --- > drivers/staging/comedi/drivers/quatech_daqp_cs.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Someone sent in this change before you did, sorry :(
Re: [PATCH] Staging: comedi: quatech_daqp_cs.c: fixed a warning issue
On Mon, May 16, 2016 at 11:04:31PM +0530, Amit Ghadge wrote: > Fixed a warning issue to use 'unsigned int'. > > Signed-off-by: Amit Ghadge > --- > drivers/staging/comedi/drivers/quatech_daqp_cs.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Doesn't apply to my tree :(
Re: [PATCH] net: lantiq_etop: remove unused variable
From: Sudip Mukherjee Date: Thu, 16 Jun 2016 22:19:31 +0100 > The variable i was declared but was never used and we were getting a > build warning for that. > > Signed-off-by: Sudip Mukherjee Applied, thanks.
Re: [PATCH v2 1/4] staging : comedi : fix type issues in s626.c
On Sat, May 28, 2016 at 10:56:48AM +0530, Ravishankar Karkala Mallikarjunayya wrote: > This is a patch to the s626.c file that fixes up a type issues like > i.e Prefer kernel type 'u8' over 'uint8_t' > Prefer kernel type 'u16' over 'uint16_t' > Prefer kernel type 'u32' over 'uint32_t' > Prefer kernel type 's16' over 'int16_t' > Prefer kernel type 's32' over 'int32_t' > found by the checkpatch.pl tool. > > Signed-off-by: Ravishankar Karkala Mallikarjunayya > Reviewed-by: Ian Abbott > --- > changes since v1: Rework This series doesn't apply at all, please rebase it and resend the whole thing against the latest version of my staging-testing branch. thanks, greg k-h
Re: [PATCH v2 4/4] Staging: comedi: fix line over 80 characters issue in s626.c
On Mon, May 30, 2016 at 03:21:27PM +0100, Luis de Bethencourt wrote: > On 28/05/16 06:26, Ravishankar Karkala Mallikarjunayya wrote: > > This is a patch to the s626.c file that fixes up a line over 80 > > characters issues found by the checkpatch.pl tool. > > > > Signed-off-by: Ravishankar Karkala Mallikarjunayya > > > > Looks good :) > > This is the only instance of the line over 80 characters Warning in that file. > > Like previous patches, no need to mention the file being fixed in the commit > message. It isn't a big deal though. > > +1 Not much I can do with at "+1", please respond with a: Acked-by: or even better: Reviewed-by: with the proper info, so I can add it to the patch and give you credit for reviewing it. thanks, greg k-h
Re: [PATCH v5 2/4] gpio: Allow PC/104 devices on X86_64
On Fri, Jun 17, 2016 at 11:39:04PM -0400, William Breathitt Gray wrote: > On Fri, Jun 17, 2016 at 08:18:10PM -0700, Greg KH wrote: > >On Fri, Jun 17, 2016 at 10:49:59PM -0400, William Breathitt Gray wrote: > >> The PC/104 drivers were changed to utilize the ISA bus driver as part of > >> the original patchset which attempted to decouple the X86_32 dependency > >> from the ISA Kconfig option; these drivers were updated with the > >> intention of building on X86_64 in addition to X86_32. > >> > >> However, the respective patches were merged without the decoupling > >> changes (since decoupling was the wrong approach), resulting in an > >> unintentional regression: the PC/104 drivers are now restricted to > >> X86_32 due to the ISA Kconfig option dependency, while they were capable > >> of building for X86_64 in previous kernel versions. > >> > >> This patchset should fix this regression by introducing the ISA_BUS_API > >> Kconfig option, and the respective Kconfig dependency changes for the > >> drivers, in order to allow them to build for both X86_64 and X86_32 as > >> originally capable. > > > >Ah, ok, that makes more sense, thanks. I'll go queue these up now. > > > >greg k-h > > Greg K-H, > > Please also consider picking up the following two patches which fix bugs > discovered during the ISA bus driver utilization conversion: > > 1. https://patchwork.kernel.org/patch/9046831/ > 2. https://patchwork.kernel.org/patch/9074641/ > > The second patch in particular fixes a kernel BUG which prevents some > drivers that call isa_register_driver from being built-in. This was > first reported by Sasha Levin (https://lkml.org/lkml/2016/5/11/719), and > the patch was later tested by Ye Xiaolong > (https://lkml.org/lkml/2016/5/31/164). Now queued up, thanks for the prompt, they were still setting in my queue. greg k-h
Re: [PATCH v5 2/4] gpio: Allow PC/104 devices on X86_64
On Fri, Jun 17, 2016 at 08:18:10PM -0700, Greg KH wrote: >On Fri, Jun 17, 2016 at 10:49:59PM -0400, William Breathitt Gray wrote: >> The PC/104 drivers were changed to utilize the ISA bus driver as part of >> the original patchset which attempted to decouple the X86_32 dependency >> from the ISA Kconfig option; these drivers were updated with the >> intention of building on X86_64 in addition to X86_32. >> >> However, the respective patches were merged without the decoupling >> changes (since decoupling was the wrong approach), resulting in an >> unintentional regression: the PC/104 drivers are now restricted to >> X86_32 due to the ISA Kconfig option dependency, while they were capable >> of building for X86_64 in previous kernel versions. >> >> This patchset should fix this regression by introducing the ISA_BUS_API >> Kconfig option, and the respective Kconfig dependency changes for the >> drivers, in order to allow them to build for both X86_64 and X86_32 as >> originally capable. > >Ah, ok, that makes more sense, thanks. I'll go queue these up now. > >greg k-h Greg K-H, Please also consider picking up the following two patches which fix bugs discovered during the ISA bus driver utilization conversion: 1. https://patchwork.kernel.org/patch/9046831/ 2. https://patchwork.kernel.org/patch/9074641/ The second patch in particular fixes a kernel BUG which prevents some drivers that call isa_register_driver from being built-in. This was first reported by Sasha Levin (https://lkml.org/lkml/2016/5/11/719), and the patch was later tested by Ye Xiaolong (https://lkml.org/lkml/2016/5/31/164). Thanks, William Breathitt Gray
[PATCH 2/4] ASoC: tap6130a2: Use regmap
Use regmap instead of open-coding IO access and caching
Signed-off-by: Lars-Peter Clausen
[koike: port for upstream]
Signed-off-by: Helen Koike
---
sound/soc/codecs/tpa6130a2.c | 166 ---
sound/soc/codecs/tpa6130a2.h | 2 -
2 files changed, 46 insertions(+), 122 deletions(-)
diff --git a/sound/soc/codecs/tpa6130a2.c b/sound/soc/codecs/tpa6130a2.c
index f700d92..0be70a4 100644
--- a/sound/soc/codecs/tpa6130a2.c
+++ b/sound/soc/codecs/tpa6130a2.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include "tpa6130a2.h"
@@ -45,92 +46,16 @@ static struct i2c_client *tpa6130a2_client;
/* This struct is used to save the context */
struct tpa6130a2_data {
struct mutex mutex;
- unsigned char regs[TPA6130A2_CACHEREGNUM];
+ struct regmap *regmap;
struct regulator *supply;
int power_gpio;
u8 power_state:1;
enum tpa_model id;
};
-static int tpa6130a2_i2c_read(int reg)
-{
- struct tpa6130a2_data *data;
- int val;
-
- if (WARN_ON(!tpa6130a2_client))
- return -EINVAL;
- data = i2c_get_clientdata(tpa6130a2_client);
-
- /* If powered off, return the cached value */
- if (data->power_state) {
- val = i2c_smbus_read_byte_data(tpa6130a2_client, reg);
- if (val < 0)
- dev_err(&tpa6130a2_client->dev, "Read failed\n");
- else
- data->regs[reg] = val;
- } else {
- val = data->regs[reg];
- }
-
- return val;
-}
-
-static int tpa6130a2_i2c_write(int reg, u8 value)
-{
- struct tpa6130a2_data *data;
- int val = 0;
-
- if (WARN_ON(!tpa6130a2_client))
- return -EINVAL;
- data = i2c_get_clientdata(tpa6130a2_client);
-
- if (data->power_state) {
- val = i2c_smbus_write_byte_data(tpa6130a2_client, reg, value);
- if (val < 0) {
- dev_err(&tpa6130a2_client->dev, "Write failed\n");
- return val;
- }
- }
-
- /* Either powered on or off, we save the context */
- data->regs[reg] = value;
-
- return val;
-}
-
-static u8 tpa6130a2_read(int reg)
-{
- struct tpa6130a2_data *data;
-
- if (WARN_ON(!tpa6130a2_client))
- return 0;
- data = i2c_get_clientdata(tpa6130a2_client);
-
- return data->regs[reg];
-}
-
-static int tpa6130a2_initialize(void)
-{
- struct tpa6130a2_data *data;
- int i, ret = 0;
-
- if (WARN_ON(!tpa6130a2_client))
- return -EINVAL;
- data = i2c_get_clientdata(tpa6130a2_client);
-
- for (i = 1; i < TPA6130A2_REG_VERSION; i++) {
- ret = tpa6130a2_i2c_write(i, data->regs[i]);
- if (ret < 0)
- break;
- }
-
- return ret;
-}
-
static int tpa6130a2_power(u8 power)
{
struct tpa6130a2_data *data;
- u8 val;
int ret = 0;
if (WARN_ON(!tpa6130a2_client))
@@ -153,7 +78,7 @@ static int tpa6130a2_power(u8 power)
gpio_set_value(data->power_gpio, 1);
data->power_state = 1;
- ret = tpa6130a2_initialize();
+ ret = regcache_sync(data->regmap);
if (ret < 0) {
dev_err(&tpa6130a2_client->dev,
"Failed to initialize chip\n");
@@ -165,9 +90,8 @@ static int tpa6130a2_power(u8 power)
}
} else {
/* set SWS */
- val = tpa6130a2_read(TPA6130A2_REG_CONTROL);
- val |= TPA6130A2_SWS;
- tpa6130a2_i2c_write(TPA6130A2_REG_CONTROL, val);
+ regmap_update_bits(data->regmap, TPA6130A2_REG_CONTROL,
+ TPA6130A2_SWS, TPA6130A2_SWS);
/* Power off */
if (data->power_gpio >= 0)
@@ -181,6 +105,8 @@ static int tpa6130a2_power(u8 power)
}
data->power_state = 0;
+ /* device regs does not match the cache state anymore */
+ regcache_mark_dirty(data->regmap);
}
exit:
@@ -196,7 +122,7 @@ static int tpa6130a2_get_volsw(struct snd_kcontrol
*kcontrol,
struct tpa6130a2_data *data;
unsigned int reg = mc->reg;
unsigned int shift = mc->shift;
- int max = mc->max;
+ int max = mc->max, val;
unsigned int mask = (1 << fls(max)) - 1;
unsigned int invert = mc->invert;
@@ -206,8 +132,8 @@ static int tpa6130a2_get_volsw(struct snd_kcontrol
*kcontrol,
mutex_lock(&data->mutex);
- ucontrol->value.integer.value[0] =
- (tpa6130a2_read(reg) >> shift) & mask;
+ regmap_read(data->regmap, reg, &val);
+ ucontrol->value.integer.value[0] = (val >> shift) & mask;
if (invert)
ucontrol->value.integer.value[0] =
@@ -2
[PATCH 1/4] ASoC: tpa6130a2: Register component
Add tpa6130a2 controls by the component API and update rx51 accordingly
Signed-off-by: Lars-Peter Clausen
[koike: port for upstream]
Signed-off-by: Helen Koike
---
sound/soc/codecs/tpa6130a2.c | 26 +-
sound/soc/codecs/tpa6130a2.h | 1 -
sound/soc/omap/rx51.c| 23 ---
3 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/sound/soc/codecs/tpa6130a2.c b/sound/soc/codecs/tpa6130a2.c
index 11d85c5..f700d92 100644
--- a/sound/soc/codecs/tpa6130a2.c
+++ b/sound/soc/codecs/tpa6130a2.c
@@ -348,23 +348,22 @@ int tpa6130a2_stereo_enable(struct snd_soc_codec *codec,
int enable)
}
EXPORT_SYMBOL_GPL(tpa6130a2_stereo_enable);
-int tpa6130a2_add_controls(struct snd_soc_codec *codec)
+static int tpa6130a2_component_probe(struct snd_soc_component *component)
{
- struct tpa6130a2_data *data;
-
- if (tpa6130a2_client == NULL)
- return -ENODEV;
-
- data = i2c_get_clientdata(tpa6130a2_client);
+ struct tpa6130a2_data *data = snd_soc_component_get_drvdata(component);
if (data->id == TPA6140A2)
- return snd_soc_add_codec_controls(codec, tpa6140a2_controls,
- ARRAY_SIZE(tpa6140a2_controls));
+ return snd_soc_add_component_controls(component,
+ tpa6140a2_controls, ARRAY_SIZE(tpa6140a2_controls));
else
- return snd_soc_add_codec_controls(codec, tpa6130a2_controls,
- ARRAY_SIZE(tpa6130a2_controls));
+ return snd_soc_add_component_controls(component,
+ tpa6130a2_controls, ARRAY_SIZE(tpa6130a2_controls));
}
-EXPORT_SYMBOL_GPL(tpa6130a2_add_controls);
+
+struct snd_soc_component_driver tpa6130a2_component_driver = {
+ .name = "tpa6130a2",
+ .probe = tpa6130a2_component_probe,
+};
static int tpa6130a2_probe(struct i2c_client *client,
const struct i2c_device_id *id)
@@ -451,7 +450,8 @@ static int tpa6130a2_probe(struct i2c_client *client,
if (ret != 0)
goto err_gpio;
- return 0;
+ return devm_snd_soc_register_component(&client->dev,
+ &tpa6130a2_component_driver, NULL, 0);
err_gpio:
tpa6130a2_client = NULL;
diff --git a/sound/soc/codecs/tpa6130a2.h b/sound/soc/codecs/tpa6130a2.h
index 4174440..78ee723 100644
--- a/sound/soc/codecs/tpa6130a2.h
+++ b/sound/soc/codecs/tpa6130a2.h
@@ -56,7 +56,6 @@
/* TPA6130A2_REG_VERSION (0x04) */
#define TPA6130A2_VERSION_MASK (0x0f)
-extern int tpa6130a2_add_controls(struct snd_soc_codec *codec);
extern int tpa6130a2_stereo_enable(struct snd_soc_codec *codec, int enable);
#endif /* __TPA6130A2_H__ */
diff --git a/sound/soc/omap/rx51.c b/sound/soc/omap/rx51.c
index 5494924..b59cf89 100644
--- a/sound/soc/omap/rx51.c
+++ b/sound/soc/omap/rx51.c
@@ -286,16 +286,10 @@ static const struct snd_kcontrol_new
aic34_rx51_controls[] = {
static int rx51_aic34_init(struct snd_soc_pcm_runtime *rtd)
{
- struct snd_soc_codec *codec = rtd->codec;
struct snd_soc_card *card = rtd->card;
struct rx51_audio_pdata *pdata = snd_soc_card_get_drvdata(card);
int err;
- err = tpa6130a2_add_controls(codec);
- if (err < 0) {
- dev_err(card->dev, "Failed to add TPA6130A2 controls\n");
- return err;
- }
snd_soc_limit_volume(card, "TPA6130A2 Headphone Playback Volume", 42);
err = omap_mcbsp_st_add_controls(rtd, 2);
@@ -357,6 +351,10 @@ static struct snd_soc_aux_dev rx51_aux_dev[] = {
.name = "TLV320AIC34b",
.codec_name = "tlv320aic3x-codec.2-0019",
},
+ {
+ .name = "TPA61320A2",
+ .codec_name = "tpa6130a2.2-0060",
+ },
};
static struct snd_soc_codec_conf rx51_codec_conf[] = {
@@ -364,6 +362,10 @@ static struct snd_soc_codec_conf rx51_codec_conf[] = {
.dev_name = "tlv320aic3x-codec.2-0019",
.name_prefix = "b",
},
+ {
+ .dev_name = "tpa6130a2.2-0060",
+ .name_prefix = "TPA6130A2",
+ },
};
/* Audio card */
@@ -435,11 +437,10 @@ static int rx51_soc_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "Headphone amplifier node is not
provided\n");
return -EINVAL;
}
-
- /* TODO: tpa6130a2a driver supports only a single instance, so
-* this driver ignores the headphone-amplifier node for now.
-* It's already mandatory in the DT binding to be future proof.
-*/
+ rx51_aux_dev[1].codec_name = NULL;
+ rx51_aux_dev[1].codec_of_node = dai_node;
+ rx51_codec_conf[1].dev_name = NULL;
+ rx51_codec_conf[1].of_node = dai_node;
}
pdata = devm_kzal
[PATCH 4/4] ASoC: tpa6130a2: Add DAPM support
Add DAPM support and updated rx51 accordingly.
As a consequence:
- the exported function tpa6130a2_stereo_enable is not needed anymore
- the mutex is dealt in the DAPM
- the power state is tracked by the DAPM
Signed-off-by: Lars-Peter Clausen
[koike: port for upstream]
Signed-off-by: Helen Koike
---
sound/soc/codecs/tpa6130a2.c | 184 +--
sound/soc/codecs/tpa6130a2.h | 11 +--
sound/soc/omap/rx51.c| 22 ++
3 files changed, 86 insertions(+), 131 deletions(-)
diff --git a/sound/soc/codecs/tpa6130a2.c b/sound/soc/codecs/tpa6130a2.c
index dc7bfc9..7cb5066 100644
--- a/sound/soc/codecs/tpa6130a2.c
+++ b/sound/soc/codecs/tpa6130a2.c
@@ -41,79 +41,71 @@ enum tpa_model {
TPA6140A2,
};
-static struct i2c_client *tpa6130a2_client;
-
/* This struct is used to save the context */
struct tpa6130a2_data {
- struct mutex mutex;
struct regmap *regmap;
struct regulator *supply;
int power_gpio;
- u8 power_state:1;
enum tpa_model id;
};
-static int tpa6130a2_power(u8 power)
+static int tpa6130a2_power(struct device *dev, bool enable)
{
- struct tpa6130a2_data *data;
- int ret = 0;
-
- if (WARN_ON(!tpa6130a2_client))
- return -EINVAL;
- data = i2c_get_clientdata(tpa6130a2_client);
-
- mutex_lock(&data->mutex);
- if (power == data->power_state)
- goto exit;
+ struct tpa6130a2_data *data = dev_get_drvdata(dev);
+ int ret;
- if (power) {
+ if (enable) {
ret = regulator_enable(data->supply);
if (ret != 0) {
- dev_err(&tpa6130a2_client->dev,
- "Failed to enable supply: %d\n", ret);
- goto exit;
+ dev_err(dev, "Failed to enable supply: %d\n", ret);
+ return ret;
}
/* Power on */
if (data->power_gpio >= 0)
gpio_set_value(data->power_gpio, 1);
-
- data->power_state = 1;
- ret = regcache_sync(data->regmap);
- if (ret < 0) {
- dev_err(&tpa6130a2_client->dev,
- "Failed to initialize chip\n");
- if (data->power_gpio >= 0)
- gpio_set_value(data->power_gpio, 0);
- regulator_disable(data->supply);
- data->power_state = 0;
- goto exit;
- }
} else {
- /* set SWS */
- regmap_update_bits(data->regmap, TPA6130A2_REG_CONTROL,
- TPA6130A2_SWS, TPA6130A2_SWS);
-
/* Power off */
if (data->power_gpio >= 0)
gpio_set_value(data->power_gpio, 0);
ret = regulator_disable(data->supply);
if (ret != 0) {
- dev_err(&tpa6130a2_client->dev,
- "Failed to disable supply: %d\n", ret);
- goto exit;
+ dev_err(dev, "Failed to disable supply: %d\n", ret);
+ return ret;
}
- data->power_state = 0;
/* device regs does not match the cache state anymore */
regcache_mark_dirty(data->regmap);
}
-exit:
- mutex_unlock(&data->mutex);
return ret;
}
+static int tpa6130a2_power_event(struct snd_soc_dapm_widget *w,
+struct snd_kcontrol *kctrl, int event)
+{
+ struct snd_soc_component *c = snd_soc_dapm_to_component(w->dapm);
+ struct tpa6130a2_data *data = snd_soc_component_get_drvdata(c);
+ int ret;
+
+ /* before widget power up */
+ if (SND_SOC_DAPM_EVENT_ON(event)) {
+ /* Turn on the chip */
+ tpa6130a2_power(c->dev, true);
+ /* Sync the registers */
+ ret = regcache_sync(data->regmap);
+ if (ret < 0) {
+ dev_err(c->dev, "Failed to initialize chip\n");
+ tpa6130a2_power(c->dev, false);
+ return ret;
+ }
+ /* after widget power down */
+ } else
+ tpa6130a2_power(c->dev, false);
+
+ return 0;
+}
+
/*
* TPA6130 volume. From -59.5 to 4 dB with increasing step size when going
* down in gain.
@@ -149,57 +141,6 @@ static const struct snd_kcontrol_new tpa6140a2_controls[]
= {
tpa6140_tlv),
};
-/*
- * Enable or disable channel (left or right)
- * The bit number for mute and amplifier are the same per channel:
- * bit 6: Right channel
- * bit 7: Left channel
- * in both registers.
- */
-static void tpa6130a2_channel_enable(u8 channel, int enable)
-{
- struct tpa6130a2_data *data = i2c_get_clientdata(tpa6130a2_cli
[PATCH 0/4] ASoC: tpa6130a2: Add support for multiple instances
The current tpa6130a2 driver supports only a single instance.
This patch series add support for multiple instances by removing the global
variable that holds the instance.
This is performed by using the component API, regmap, the
snd_soc_{info,put,get}_volsw API and DAPM.
This patch series also touches code from the Nokia RX51 which I didn't tested
(as
I am testing the tpa6130a2 in another board that is not upstream).
I would appreciate is if someone who possesses the Nokia RX51 (n900) could
please
test the code.
This patch series is based on
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Available at
https://git.collabora.com/cgit/user/koike/linux.git/log/?h=sound/review/tpa6130a2
Helen Koike (4):
ASoC: tpa6130a2: Register component
ASoC: tap6130a2: Use regmap
ASoC: tpa6130a2: Use snd soc volsw functions
ASoC: tpa6130a2: Add DAPM support
sound/soc/codecs/tpa6130a2.c | 382 ---
sound/soc/codecs/tpa6130a2.h | 14 +-
sound/soc/omap/rx51.c| 45 ++---
3 files changed, 130 insertions(+), 311 deletions(-)
--
1.9.1
[PATCH 3/4] ASoC: tpa6130a2: Use snd soc volsw functions
Use snd_soc_{info,get,put}_volsw instead of custom volume functions
Signed-off-by: Lars-Peter Clausen
[koike: port for upstream]
Signed-off-by: Helen Koike
---
sound/soc/codecs/tpa6130a2.c | 64 ++--
1 file changed, 2 insertions(+), 62 deletions(-)
diff --git a/sound/soc/codecs/tpa6130a2.c b/sound/soc/codecs/tpa6130a2.c
index 0be70a4..dc7bfc9 100644
--- a/sound/soc/codecs/tpa6130a2.c
+++ b/sound/soc/codecs/tpa6130a2.c
@@ -114,64 +114,6 @@ exit:
return ret;
}
-static int tpa6130a2_get_volsw(struct snd_kcontrol *kcontrol,
- struct snd_ctl_elem_value *ucontrol)
-{
- struct soc_mixer_control *mc =
- (struct soc_mixer_control *)kcontrol->private_value;
- struct tpa6130a2_data *data;
- unsigned int reg = mc->reg;
- unsigned int shift = mc->shift;
- int max = mc->max, val;
- unsigned int mask = (1 << fls(max)) - 1;
- unsigned int invert = mc->invert;
-
- if (WARN_ON(!tpa6130a2_client))
- return -EINVAL;
- data = i2c_get_clientdata(tpa6130a2_client);
-
- mutex_lock(&data->mutex);
-
- regmap_read(data->regmap, reg, &val);
- ucontrol->value.integer.value[0] = (val >> shift) & mask;
-
- if (invert)
- ucontrol->value.integer.value[0] =
- max - ucontrol->value.integer.value[0];
-
- mutex_unlock(&data->mutex);
- return 0;
-}
-
-static int tpa6130a2_put_volsw(struct snd_kcontrol *kcontrol,
- struct snd_ctl_elem_value *ucontrol)
-{
- struct soc_mixer_control *mc =
- (struct soc_mixer_control *)kcontrol->private_value;
- struct tpa6130a2_data *data;
- unsigned int reg = mc->reg;
- unsigned int shift = mc->shift;
- int max = mc->max;
- unsigned int mask = (1 << fls(max)) - 1;
- unsigned int invert = mc->invert;
- unsigned int val = (ucontrol->value.integer.value[0] & mask);
- bool change;
-
- if (WARN_ON(!tpa6130a2_client))
- return -EINVAL;
- data = i2c_get_clientdata(tpa6130a2_client);
-
- if (invert)
- val = max - val;
-
- mutex_lock(&data->mutex);
- regmap_update_bits_check(data->regmap, reg, mask << shift, val << shift,
-&change);
- mutex_unlock(&data->mutex);
-
- return change;
-}
-
/*
* TPA6130 volume. From -59.5 to 4 dB with increasing step size when going
* down in gain.
@@ -190,9 +132,8 @@ static const DECLARE_TLV_DB_RANGE(tpa6130_tlv,
);
static const struct snd_kcontrol_new tpa6130a2_controls[] = {
- SOC_SINGLE_EXT_TLV("TPA6130A2 Headphone Playback Volume",
+ SOC_SINGLE_TLV("TPA6130A2 Headphone Playback Volume",
TPA6130A2_REG_VOL_MUTE, 0, 0x3f, 0,
- tpa6130a2_get_volsw, tpa6130a2_put_volsw,
tpa6130_tlv),
};
@@ -203,9 +144,8 @@ static const DECLARE_TLV_DB_RANGE(tpa6140_tlv,
);
static const struct snd_kcontrol_new tpa6140a2_controls[] = {
- SOC_SINGLE_EXT_TLV("TPA6140A2 Headphone Playback Volume",
+ SOC_SINGLE_TLV("TPA6140A2 Headphone Playback Volume",
TPA6130A2_REG_VOL_MUTE, 1, 0x1f, 0,
- tpa6130a2_get_volsw, tpa6130a2_put_volsw,
tpa6140_tlv),
};
--
1.9.1
Re: [PATCH 2/3] staging: lustre: lnet: Allocate MEs and small MDs in own kmem_caches
On Wed, Jun 15, 2016 at 04:02:40AM +0100, James Simmons wrote: > > > > This may also possibly help to save cycles due to high usage and > > > contention when using a generic kmem_cache (when they stay separate > > > from others, thanks for the precision!). > > > > Have you measured this? > > > > This isn't applicable for 4.7-rc at this time, _unless_ it fixes a bug, > > which is why I pushed back on this. If you want your own cache for > > these variables, fine, I don't care, but that makes it a 4.8-rc1 patch > > instead. > > > > hope that helps explain things better, > > As a side question when is the window to push patches of this class? > Is it when 4.7-rc7 is merged to staging? You can send them to me anytime, I'll queue them up in my "-next" branch to be merged in the next merge window. Like I do for almost all lustre patches that aren't bugfixes or regressions. But I think you have a bigger problem here that you need to debug, using a separate cache isn't going to solve that bug, only postpone you finding it... thanks, greg k-h
Re: [PATCH v2] ION: Sys_heap: Add cached pool to spead up cached buffer alloc
Greg, I checkout your staging tree[1]. Not find this patch. Can you take it thanks! [1]git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git On 2016/6/5 23:02, Greg KH wrote: > On Sun, Jun 05, 2016 at 04:51:23PM +0800, Chen Feng wrote: >> Hi Greg, >> >> Can you take this patch? > > It's in my queue, please wait, staging patches are at the bottom of it, > rightfully so... > > thanks, > > greg k-h > > . >
Re: [PATCH v5 2/4] gpio: Allow PC/104 devices on X86_64
On Fri, Jun 17, 2016 at 10:49:59PM -0400, William Breathitt Gray wrote: > On Fri, Jun 17, 2016 at 07:36:07PM -0700, Greg KH wrote: > >On Fri, Jun 17, 2016 at 12:47:14PM +0200, Thorsten Leemhuis wrote: > >> On 31.05.2016 17:25, Greg KH wrote: > >> > On Tue, May 31, 2016 at 07:23:06AM -0400, William Breathitt Gray wrote: > >> >> On Tue, May 31, 2016 at 10:41:49AM +0200, Linus Walleij wrote: > >> >>> On Sat, May 28, 2016 at 12:08 AM, William Breathitt Gray > >> >>> wrote: > >> With the introduction of the ISA_BUS_API Kconfig option, ISA-style > >> drivers may be built for X86_64 architectures. This patch changes the > >> ISA Kconfig option dependency of the PC/104 drivers to ISA_BUS_API, > >> thus > >> allowing them to build for X86_64 as they are expected to. > >> > […] > >> >> Greg K-H, > >> >> > >> >> Would you be able to pick up this entire patchset via driver-core; I > >> >> figure that tree is the most appropriate to receive any core ISA bus > >> >> driver changes (unless you see a more fitting path to take). > >> > […] > >> > Yes, I can take this through the driver core tree as that's where the > >> > original series came from... > >> > >> Was this series merged or did it fell through the cracks? I currently > >> assume the latter, as I can't see it in neither mainline nor linux-next > >> (but maybe I'm missing something). Just wondering, because I have this > >> issue on my regression list for 4.7. > >> > >> For the whole context see: > >> http://thread.gmane.org/gmane.linux.kernel.gpio/17016/ > >> > >> Sincerely, your regression tracker for Linux 4.7 (http://bit.ly/28JRmJo) > > > >I don't think this is a regression, I was going to queue these up for > >4.8-rc1. As it is now, 4.7-rc is working just fine in this regards, > >right? > > > >Or am I missing something? > > The PC/104 drivers were changed to utilize the ISA bus driver as part of > the original patchset which attempted to decouple the X86_32 dependency > from the ISA Kconfig option; these drivers were updated with the > intention of building on X86_64 in addition to X86_32. > > However, the respective patches were merged without the decoupling > changes (since decoupling was the wrong approach), resulting in an > unintentional regression: the PC/104 drivers are now restricted to > X86_32 due to the ISA Kconfig option dependency, while they were capable > of building for X86_64 in previous kernel versions. > > This patchset should fix this regression by introducing the ISA_BUS_API > Kconfig option, and the respective Kconfig dependency changes for the > drivers, in order to allow them to build for both X86_64 and X86_32 as > originally capable. Ah, ok, that makes more sense, thanks. I'll go queue these up now. greg k-h
[GIT PULL] liblockdep fixes for 4.7
Hey Ingo, Please pull a bunch of fixes for liblockdep from Ben and Vishal. Mostly build failures as a result of kernel changes. Thanks, Sasha === The following changes since commit 1a695a905c18548062509178b98bc91e67510864: Linux 4.7-rc1 (2016-05-29 09:29:24 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux.git HEAD for you to fetch changes up to d7906160b2bc8f1be513b7e01b8783a50637092c: liblockdep: Remove -lpthread compiler option (2016-06-14 18:13:49 -0400) Ben Hutchings (7): liblockdep: Fix undefined symbol prandom_u32 liblockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain::depth liblockdep: Define the ARRAY_SIZE() macro liblockdep: Enable -Wall by default liblockdep: Fix 'unused value' warnings liblockdep: Fix 'set but not used' warnings liblockdep: Fix 'defined but not used' warning for init_utsname() Vishal Thanki (1): liblockdep: Remove -lpthread compiler option tools/lib/lockdep/Makefile | 1 + tools/lib/lockdep/lockdep.c| 17 + tools/lib/lockdep/run_tests.sh | 4 ++-- tools/lib/lockdep/uinclude/linux/debug_locks.h | 2 +- tools/lib/lockdep/uinclude/linux/irqflags.h| 8 tools/lib/lockdep/uinclude/linux/kernel.h | 14 +++--- tools/lib/lockdep/uinclude/linux/lockdep.h | 18 ++ 7 files changed, 42 insertions(+), 22 deletions(-)
Stable -rc git trees and email headers
Hi, I've finally gotten off my butt and made my quilt trees of patches into a "semi-proper" git tree to make it easier for people to test them. I'm now pushing the patches I accept into the stable queues into the git tree here: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git I'll push them out in chunks, as I accept them, and when I do a "real" -rc release. Right now the HEAD of each branch will have a -rc1 tag on them, just because it makes it a bit easier on my end. Note these branches WILL get rebased. All the time. So don't count on them to contain anything that will stick around, UNTIL a real stable release happens. Guenter, I hope this helps with your testing, is there anything that I can do here to make it easier for you? Kevin, hopefully this tree also helps you. I will also be adding some email headers to my announcements of the -rc releases that you can parse. Here is what they are going to look like for an example release: X-KernelTest-Patch: http://kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.14-rc1.gz X-KernelTest-Tree: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git X-KernelTest-Branch: linux-4.4.y X-KernelTest-Patches: git://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git X-KernelTest-Version: 4.4.14-rc1 X-KernelTest-Deadline: 2016-06-20T02:57+00:00 Will those work out? Fengguang, can you add these to the 0-day bot? The branches to watch are all of the currently-active stable trees. Right now that would be "linux-3.14.y", "linux-4.4.y", and "linux-4.6.y". Do I need to tell you about future branches, or can you just pick up new ones when they show up? And can I get announcements if/when the tests pass (or fail) so I know all is ok? Hope this helps people out, thanks, greg k-h
Re: [PATCH v8 2/4] power: reset: add reboot mode driver
Hi Sebastian: On 2016年06月16日 22:36, Sebastian Reichel wrote: Hi, On Mon, Apr 25, 2016 at 02:55:36PM +0800, Andy Yan wrote: This driver parses the reboot commands like "reboot bootloader" and "reboot recovery" to get a boot mode described in the device tree , then call the write interfae to store the boot mode in some place like special register or sram, which can be read by the bootloader after system reboot, then the bootloader can take different action according to the mode stored. This is commonly used on Android based devices, in order to reboot the device into fastboot or recovery mode. Reviewed-by: Matthias Brugger Reviewed-by: Moritz Fischer Tested-by: John Stultz Acked-by: John Stultz Signed-off-by: Andy Yan What's the status of this patchset? It still has a few open comments/issues, but I did not see a newer version. -- Sebastian Sorry for the delay, I will send a new version next week.
Re: [PATCH v5 2/4] gpio: Allow PC/104 devices on X86_64
On Fri, Jun 17, 2016 at 07:36:07PM -0700, Greg KH wrote: >On Fri, Jun 17, 2016 at 12:47:14PM +0200, Thorsten Leemhuis wrote: >> On 31.05.2016 17:25, Greg KH wrote: >> > On Tue, May 31, 2016 at 07:23:06AM -0400, William Breathitt Gray wrote: >> >> On Tue, May 31, 2016 at 10:41:49AM +0200, Linus Walleij wrote: >> >>> On Sat, May 28, 2016 at 12:08 AM, William Breathitt Gray >> >>> wrote: >> With the introduction of the ISA_BUS_API Kconfig option, ISA-style >> drivers may be built for X86_64 architectures. This patch changes the >> ISA Kconfig option dependency of the PC/104 drivers to ISA_BUS_API, thus >> allowing them to build for X86_64 as they are expected to. >> > […] >> >> Greg K-H, >> >> >> >> Would you be able to pick up this entire patchset via driver-core; I >> >> figure that tree is the most appropriate to receive any core ISA bus >> >> driver changes (unless you see a more fitting path to take). >> > […] >> > Yes, I can take this through the driver core tree as that's where the >> > original series came from... >> >> Was this series merged or did it fell through the cracks? I currently >> assume the latter, as I can't see it in neither mainline nor linux-next >> (but maybe I'm missing something). Just wondering, because I have this >> issue on my regression list for 4.7. >> >> For the whole context see: >> http://thread.gmane.org/gmane.linux.kernel.gpio/17016/ >> >> Sincerely, your regression tracker for Linux 4.7 (http://bit.ly/28JRmJo) > >I don't think this is a regression, I was going to queue these up for >4.8-rc1. As it is now, 4.7-rc is working just fine in this regards, >right? > >Or am I missing something? The PC/104 drivers were changed to utilize the ISA bus driver as part of the original patchset which attempted to decouple the X86_32 dependency from the ISA Kconfig option; these drivers were updated with the intention of building on X86_64 in addition to X86_32. However, the respective patches were merged without the decoupling changes (since decoupling was the wrong approach), resulting in an unintentional regression: the PC/104 drivers are now restricted to X86_32 due to the ISA Kconfig option dependency, while they were capable of building for X86_64 in previous kernel versions. This patchset should fix this regression by introducing the ISA_BUS_API Kconfig option, and the respective Kconfig dependency changes for the drivers, in order to allow them to build for both X86_64 and X86_32 as originally capable. William Breathitt Gray
Re: [PATCH v5 2/4] gpio: Allow PC/104 devices on X86_64
On Fri, Jun 17, 2016 at 12:47:14PM +0200, Thorsten Leemhuis wrote: > On 31.05.2016 17:25, Greg KH wrote: > > On Tue, May 31, 2016 at 07:23:06AM -0400, William Breathitt Gray wrote: > >> On Tue, May 31, 2016 at 10:41:49AM +0200, Linus Walleij wrote: > >>> On Sat, May 28, 2016 at 12:08 AM, William Breathitt Gray > >>> wrote: > With the introduction of the ISA_BUS_API Kconfig option, ISA-style > drivers may be built for X86_64 architectures. This patch changes the > ISA Kconfig option dependency of the PC/104 drivers to ISA_BUS_API, thus > allowing them to build for X86_64 as they are expected to. > > […] > >> Greg K-H, > >> > >> Would you be able to pick up this entire patchset via driver-core; I > >> figure that tree is the most appropriate to receive any core ISA bus > >> driver changes (unless you see a more fitting path to take). > > […] > > Yes, I can take this through the driver core tree as that's where the > > original series came from... > > Was this series merged or did it fell through the cracks? I currently > assume the latter, as I can't see it in neither mainline nor linux-next > (but maybe I'm missing something). Just wondering, because I have this > issue on my regression list for 4.7. > > For the whole context see: > http://thread.gmane.org/gmane.linux.kernel.gpio/17016/ > > Sincerely, your regression tracker for Linux 4.7 (http://bit.ly/28JRmJo) I don't think this is a regression, I was going to queue these up for 4.8-rc1. As it is now, 4.7-rc is working just fine in this regards, right? Or am I missing something? thanks, greg k-h
[PATCH v13 06/16] sparc/PCI: Reserve legacy mmio after PCI mmio
On one system found bunch of claim resource fail from pci device.
pci_sun4v f02b894c: PCI host bridge to bus :00
pci_bus :00: root bus resource [io 0x2007e-0x2007e0fff] (bus
address [0x-0xfff])
pci_bus :00: root bus resource [mem 0x2-0x27eff] (bus
address [0x-0x7eff])
pci_bus :00: root bus resource [mem 0x20001-0x20007] (bus
address [0x1-0x7])
...
PCI: Claiming :00:02.0: Resource 14: 0002..0002004f
[200]
pci :00:02.0: can't claim BAR 14 [mem 0x2-0x2004f]:
address conflict with Video RAM area [??? 0x2000a-0x2000b flags
0x8000]
pci :02:00.0: can't claim BAR 0 [mem 0x2-0x2000f]: no
compatible bridge window
PCI: Claiming :02:00.0: Resource 3: 00020010..000200103fff [200]
pci :02:00.0: can't claim BAR 3 [mem 0x20010-0x200103fff]: no
compatible bridge window
PCI: Claiming :02:00.1: Resource 0: 00020020..0002002f [200]
pci :02:00.1: can't claim BAR 0 [mem 0x20020-0x2002f]: no
compatible bridge window
PCI: Claiming :02:00.1: Resource 3: 000200104000..000200107fff [200]
pci :02:00.1: can't claim BAR 3 [mem 0x200104000-0x200107fff]: no
compatible bridge window
PCI: Claiming :02:00.2: Resource 0: 00020030..0002003f [200]
pci :02:00.2: can't claim BAR 0 [mem 0x20030-0x2003f]: no
compatible bridge window
PCI: Claiming :02:00.2: Resource 3: 000200108000..00020010bfff [200]
pci :02:00.2: can't claim BAR 3 [mem 0x200108000-0x20010bfff]: no
compatible bridge window
PCI: Claiming :02:00.3: Resource 0: 00020040..0002004f [200]
pci :02:00.3: can't claim BAR 0 [mem 0x20040-0x2004f]: no
compatible bridge window
PCI: Claiming :02:00.3: Resource 3: 00020010c000..00020010 [200]
pci :02:00.3: can't claim BAR 3 [mem 0x20010c000-0x20010]: no
compatible bridge window
The bridge 00:02.0 resource does not get reserved as Video RAM take the
position early,
and following children resources reservation all fail.
Move down Video RAM area reservation after pci mmio get reserved,
so we leave pci driver to use those regions.
-v5: merge simplify one and use pcibios_bus_to_resource()
-v6: use pci_find_bus_resource()
Signed-off-by: Yinghai Lu
Tested-by: Khalid Aziz
Cc: sparcli...@vger.kernel.org
---
arch/sparc/kernel/pci.c| 1 +
arch/sparc/kernel/pci_common.c | 59 ++
arch/sparc/kernel/pci_impl.h | 1 +
3 files changed, 33 insertions(+), 28 deletions(-)
diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index e16da35..654cf21 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -686,6 +686,7 @@ struct pci_bus *pci_scan_one_pbm(struct pci_pbm_info *pbm,
pci_bus_register_of_sysfs(bus);
pci_claim_bus_resources(bus);
+ pci_register_legacy_regions(bus);
pci_bus_add_devices(bus);
return bus;
}
diff --git a/arch/sparc/kernel/pci_common.c b/arch/sparc/kernel/pci_common.c
index 76998f8..1ebc7ff 100644
--- a/arch/sparc/kernel/pci_common.c
+++ b/arch/sparc/kernel/pci_common.c
@@ -328,41 +328,46 @@ void pci_get_pbm_props(struct pci_pbm_info *pbm)
}
}
-static void pci_register_legacy_regions(struct resource *io_res,
- struct resource *mem_res)
+static void pci_register_region(struct pci_bus *bus, const char *name,
+ resource_size_t rstart, resource_size_t size)
{
- struct resource *p;
+ struct resource *res, *conflict, *bus_res;
+ struct pci_bus_region region;
- /* VGA Video RAM. */
- p = kzalloc(sizeof(*p), GFP_KERNEL);
- if (!p)
+ res = kzalloc(sizeof(*res), GFP_KERNEL);
+ if (!res)
return;
- p->name = "Video RAM area";
- p->start = mem_res->start + 0xaUL;
- p->end = p->start + 0x1UL;
- p->flags = IORESOURCE_BUSY;
- request_resource(mem_res, p);
+ res->flags = IORESOURCE_MEM;
- p = kzalloc(sizeof(*p), GFP_KERNEL);
- if (!p)
+ region.start = rstart;
+ region.end = rstart + size - 1UL;
+ pcibios_bus_to_resource(bus, res, ®ion);
+ bus_res = pci_find_bus_resource(bus, res);
+ if (!bus_res) {
+ kfree(res);
return;
+ }
+
+ res->name = name;
+ res->flags |= IORESOURCE_BUSY;
+ conflict = request_resource_conflict(bus_res, res);
+ if (conflict) {
+ dev_printk(KERN_DEBUG, &bus->dev,
+ " can't claim %s %pR: address conflict with %s %pR\n",
+ res->name, res, conflict->name, conflict);
+ kfree(res);
+ }
+}
- p->name = "System ROM";
-
[PATCH v13 15/16] PCI: Only treat non-pref mmio64 as pref if host bridge has mmio64
If host bridge does not have mmio64 above 4G, We don't need to
treat device non-pref mmio64 as as pref mmio64.
Signed-off-by: Yinghai Lu
Tested-by: Khalid Aziz
---
drivers/pci/setup-bus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index ffb1941..9404032 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -741,7 +741,7 @@ int pci_claim_bridge_resource(struct pci_dev *bridge, int i)
static bool pci_up_path_over_pref_mem64(struct pci_bus *bus)
{
if (pci_is_root_bus(bus))
- return true;
+ return to_pci_host_bridge(bus->bridge)->has_mem64;
if (bus->self) {
int i;
--
2.8.3
[PATCH v13 13/16] PCI: Only treat non-pref mmio64 as pref if all bridges have MEM_64
If any bridge up to root only have 32bit pref mmio, We don't need to
treat device non-pref mmio64 as as pref mmio64.
We need to move pci_bridge_check_ranges calling early.
For parent bridges pref mmio BAR may not allocated by BIOS, res flags
is still 0, we need to have it correct set before we check them for
child device resources.
-v2: check all bus resources instead of just res[15].
Signed-off-by: Yinghai Lu
Tested-by: Khalid Aziz
---
drivers/pci/setup-bus.c | 31 +--
1 file changed, 29 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index b3b1565..ffb1941 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -738,6 +738,29 @@ int pci_claim_bridge_resource(struct pci_dev *bridge, int
i)
return -EINVAL;
}
+static bool pci_up_path_over_pref_mem64(struct pci_bus *bus)
+{
+ if (pci_is_root_bus(bus))
+ return true;
+
+ if (bus->self) {
+ int i;
+ bool found = false;
+ struct resource *res;
+
+ pci_bus_for_each_resource(bus, res, i)
+ if (res->flags & IORESOURCE_MEM_64) {
+ found = true;
+ break;
+ }
+
+ if (!found)
+ return false;
+ }
+
+ return pci_up_path_over_pref_mem64(bus->parent);
+}
+
int pci_resource_pref_compatible(const struct pci_dev *dev,
struct resource *res)
{
@@ -746,7 +769,8 @@ int pci_resource_pref_compatible(const struct pci_dev *dev,
if ((res->flags & IORESOURCE_MEM) &&
(res->flags & IORESOURCE_MEM_64) &&
- dev->on_all_pcie_path)
+ dev->on_all_pcie_path &&
+ pci_up_path_over_pref_mem64(dev->bus))
return res->flags | IORESOURCE_PREFETCH;
return res->flags;
@@ -1239,6 +1263,10 @@ void __pci_bus_size_bridges(struct pci_bus *bus, struct
list_head *realloc_head)
struct resource *b_res;
int ret;
+ if (!pci_is_root_bus(bus) &&
+ (bus->self->class >> 8) == PCI_CLASS_BRIDGE_PCI)
+ pci_bridge_check_ranges(bus);
+
list_for_each_entry(dev, &bus->devices, bus_list) {
struct pci_bus *b = dev->subordinate;
if (!b)
@@ -1266,7 +1294,6 @@ void __pci_bus_size_bridges(struct pci_bus *bus, struct
list_head *realloc_head)
break;
case PCI_CLASS_BRIDGE_PCI:
- pci_bridge_check_ranges(bus);
if (bus->self->is_hotplug_bridge) {
additional_io_size = pci_hotplug_io_size;
additional_mem_size = pci_hotplug_mem_size;
--
2.8.3
[PATCH v13 09/16] powerpc/PCI: Keep resource idx order with bridge register number
Same as sparc version.
Make resource with consistent sequence
like other arch or directly from pci_read_bridge_bases(),
even when non-pref mmio is missing, or out of ordering in firmware reporting.
Just hold i = 1 for non pref mmio, and i = 2 for pref mmio.
Signed-off-by: Yinghai Lu
Cc: linuxppc-...@lists.ozlabs.org
---
arch/powerpc/kernel/pci_of_scan.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/pci_of_scan.c
b/arch/powerpc/kernel/pci_of_scan.c
index 526ac67..719f225 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -252,7 +252,7 @@ void of_scan_pci_bridge(struct pci_dev *dev)
bus->resource[i] = res;
++res;
}
- i = 1;
+ i = 3;
for (; len >= 32; len -= 32, ranges += 8) {
flags = pci_parse_of_flags(of_read_number(ranges, 1), 1);
size = of_read_number(&ranges[6], 2);
@@ -265,6 +265,12 @@ void of_scan_pci_bridge(struct pci_dev *dev)
" for bridge %s\n", node->full_name);
continue;
}
+ } else if ((flags & IORESOURCE_PREFETCH) &&
+ !bus->resource[2]->flags) {
+ res = bus->resource[2];
+ } else if (((flags & (IORESOURCE_MEM | IORESOURCE_PREFETCH)) ==
+ IORESOURCE_MEM) && !bus->resource[1]->flags) {
+ res = bus->resource[1];
} else {
if (i >= PCI_NUM_RESOURCES - PCI_BRIDGE_RESOURCES) {
printk(KERN_ERR "PCI: too many memory ranges"
--
2.8.3
[PATCH v13 16/16] PCI: Restore pref MMIO allocation logic for host bridge without mmio64
>From 5b2854155 (PCI: Restrict 64-bit prefetchable bridge windows to 64-bit
resources), we change the logic for pref mmio allocation:
When bridge pref support mmio64, we will only put children pref
that support mmio64 into it, and will put children pref mmio32
into bridge's non-pref mmio32.
That could leave bridge pref bar not used when that pref bar is mmio64,
and children res only has mmio32.
Also could have allocation failure when non-pref mmio32 is not big
enough space for those children pref mmio32.
That is not rational when the host bridge does not have 64bit mmio
above 4g at all.
The patch restore to old logic:
when host bridge does not have has_mem64, put children pref mmio64 and
pref mmio32 all under bridges pref bars.
Signed-off-by: Yinghai Lu
Tested-by: Khalid Aziz
---
drivers/pci/bus.c | 4 +++-
drivers/pci/setup-bus.c | 13 +
drivers/pci/setup-res.c | 9 ++---
3 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index dd7cdbe..f116296 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -204,8 +204,10 @@ int pci_bus_alloc_resource(struct pci_bus *bus, struct
resource *res,
{
#ifdef CONFIG_PCI_BUS_ADDR_T_64BIT
int rc;
+ unsigned long mmio64 = pci_find_host_bridge(bus)->has_mem64 ?
+ IORESOURCE_MEM_64 : 0;
- if (res->flags & IORESOURCE_MEM_64) {
+ if (res->flags & mmio64) {
rc = pci_bus_alloc_from_region(bus, res, size, align, min,
type_mask, alignf, alignf_data,
&pci_high);
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 9404032..0845a57 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -1311,7 +1311,8 @@ void __pci_bus_size_bridges(struct pci_bus *bus, struct
list_head *realloc_head)
b_res = &bus->self->resource[PCI_BRIDGE_RESOURCES];
mask = IORESOURCE_MEM;
prefmask = IORESOURCE_MEM | IORESOURCE_PREFETCH;
- if (b_res[2].flags & IORESOURCE_MEM_64) {
+ if ((b_res[2].flags & IORESOURCE_MEM_64) &&
+ pci_find_host_bridge(bus)->has_mem64) {
prefmask |= IORESOURCE_MEM_64;
ret = pbus_size_mem(bus, prefmask, prefmask,
prefmask, prefmask,
@@ -1513,17 +1514,21 @@ static void pci_bridge_release_resources(struct pci_bus
*bus,
*io port.
* 2. if there is non pref mmio assign fail, release bridge
*nonpref mmio.
-* 3. if there is 64bit pref mmio assign fail, and bridge pref
+* 3. if there is pref mmio assign fail, and host bridge does
+*have 64bit mmio, release bridge pref mmio.
+* 4. if there is 64bit pref mmio assign fail, and bridge pref
*is 64bit, release bridge pref mmio.
-* 4. if there is pref mmio assign fail, and bridge pref is
+* 5. if there is pref mmio assign fail, and bridge pref is
*32bit mmio, release bridge pref mmio
-* 5. if there is pref mmio assign fail, and bridge pref is not
+* 6. if there is pref mmio assign fail, and bridge pref is not
*assigned, release bridge nonpref mmio.
*/
if (type & IORESOURCE_IO)
idx = 0;
else if (!(type & IORESOURCE_PREFETCH))
idx = 1;
+ else if (!pci_find_host_bridge(bus)->has_mem64)
+ idx = 2;
else if ((type & IORESOURCE_MEM_64) &&
(b_res[2].flags & IORESOURCE_MEM_64))
idx = 2;
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index f741fed..59271ee 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -212,6 +212,8 @@ static int __pci_assign_resource(struct pci_bus *bus,
struct pci_dev *dev,
struct resource *res = dev->resource + resno;
resource_size_t min;
int ret;
+ unsigned long mmio64 = pci_find_host_bridge(bus)->has_mem64 ?
+ IORESOURCE_MEM_64 : 0;
min = (res->flags & IORESOURCE_IO) ? PCIBIOS_MIN_IO : PCIBIOS_MIN_MEM;
@@ -223,7 +225,7 @@ static int __pci_assign_resource(struct pci_bus *bus,
struct pci_dev *dev,
* things differently than they were sized, not everything will fit.
*/
ret = pci_bus_alloc_resource(bus, res, size, align, min,
-IORESOURCE_PREFETCH | IORESOURCE_MEM_64,
+IORESOURCE_PREFETCH | mmio64,
pcibios_align_resource, dev);
if (ret == 0)
return 0;
@@ -232,7 +234,8 @@ static int __pci_assign_resource(struct pci_bus *bus,
struct pci_dev *dev,
* If the prefetchable window is only 32 bits wide, we can pu
[PATCH v13 14/16] PCI: Add has_mem64 for struct host_bridge
Add has_mem64 for struct host_bridge, on root bus that does not support
mmio64 above 4g, will not set that.
We will use that info next two following patches:
1. Don't treat non-pref mmio64 as pref mmio, so will not put
it under bridge's pref range when rescan the devices
2. will keep pref mmio64 and pref mmio32 under bridge pref bar.
Signed-off-by: Yinghai Lu
Tested-by: Khalid Aziz
---
drivers/pci/probe.c | 7 +++
include/linux/pci.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 5d11dec..90091fa 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -2231,6 +2231,13 @@ struct pci_bus *pci_create_root_bus(struct device
*parent, int bus,
} else
bus_addr[0] = '\0';
dev_info(&b->dev, "root bus resource %pR%s\n", res, bus_addr);
+
+ if (resource_type(res) == IORESOURCE_MEM) {
+ if ((res->end - offset) > 0x)
+ bridge->has_mem64 = 1;
+ if ((res->start - offset) > 0x)
+ res->flags |= IORESOURCE_MEM_64;
+ }
}
down_write(&pci_bus_sem);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 3f158c4..5bb8441 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -406,6 +406,7 @@ struct pci_host_bridge {
void (*release_fn)(struct pci_host_bridge *);
void *release_data;
unsigned int ignore_reset_delay:1; /* for entire hierarchy */
+ unsigned int has_mem64:1;
/* Resource alignment requirements */
resource_size_t (*align_resource)(struct pci_dev *dev,
const struct resource *res,
--
2.8.3
[PATCH v13 05/16] PCI: Add pci_find_bus_resource()
Add pci_find_bus_resource() to return bus resource for input resource.
In some case, we may only have bus instead of dev.
It is same as pci_find_parent_resource, but take bus as input.
Signed-off-by: Yinghai Lu
---
drivers/pci/pci.c | 27 ---
include/linux/pci.h | 2 ++
2 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index c8b4dbd..81c6cf9 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -414,18 +414,9 @@ int pci_find_ht_capability(struct pci_dev *dev, int ht_cap)
}
EXPORT_SYMBOL_GPL(pci_find_ht_capability);
-/**
- * pci_find_parent_resource - return resource region of parent bus of given
region
- * @dev: PCI device structure contains resources to be searched
- * @res: child resource record for which parent is sought
- *
- * For given resource region of given device, return the resource
- * region of parent bus the given region is contained in.
- */
-struct resource *pci_find_parent_resource(const struct pci_dev *dev,
- struct resource *res)
+struct resource *pci_find_bus_resource(const struct pci_bus *bus,
+ struct resource *res)
{
- const struct pci_bus *bus = dev->bus;
struct resource *r;
int i;
@@ -455,6 +446,20 @@ struct resource *pci_find_parent_resource(const struct
pci_dev *dev,
}
return NULL;
}
+
+/**
+ * pci_find_parent_resource - return resource region of parent bus of given
region
+ * @dev: PCI device structure contains resources to be searched
+ * @res: child resource record for which parent is sought
+ *
+ * For given resource region of given device, return the resource
+ * region of parent bus the given region is contained in.
+ */
+struct resource *pci_find_parent_resource(const struct pci_dev *dev,
+ struct resource *res)
+{
+ return pci_find_bus_resource(dev->bus, res);
+}
EXPORT_SYMBOL(pci_find_parent_resource);
/**
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 9c201d4..8214b24 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -805,6 +805,8 @@ void pcibios_resource_to_bus(struct pci_bus *bus, struct
pci_bus_region *region,
struct resource *res);
void pcibios_bus_to_resource(struct pci_bus *bus, struct resource *res,
struct pci_bus_region *region);
+struct resource *pci_find_bus_resource(const struct pci_bus *bus,
+ struct resource *res);
void pcibios_scan_specific_bus(int busn);
struct pci_bus *pci_find_bus(int domain, int busnr);
void pci_bus_add_devices(const struct pci_bus *bus);
--
2.8.3
[PATCH v13 00/16] PCI: Fixup for 64bit resource with sparc
Hi Bjorn, After 5b28541552ef (PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources), we have several reports on resource allocation failure, and we try to fix the problem with resource clip, and find more problems. One is from sparc that have problem with clip as we don't parse mem64 for it. This patchset try to fix the problem for sparc. patch 1-3: try to fix the pci mmap for proc path for sparc, that will make fix for sparc 64bit resource offset handling much simple. patch 4-11: parse MEM64 for sparc and other system with OF. So device 64bit resource could find their parent resource. patch 12-15: MMIO64 handling enhancement treat non-pref mmio64 if parent bridges are all pcie. patch 16: restore old pref allocation logic if hostbridge does not support mmio64. Khalid Aziz tested on some sparc platforms that have different offset to mem space start or support 64bit mmio. -v13: update patchset with pci/resource that have pci_resource_to_user changes. date 2016-06-17 Hope we can get them into v4.8. Thanks Yinghai Yinghai Lu (16): PCI: Let pci_mmap_page_range() take resource address PCI: Remove __pci_mmap_make_offset() PCI: Check resource alignment for /sys pci_mmap_resource path sparc/PCI: Use correct offset for bus address to resource PCI: Add pci_find_bus_resource() sparc/PCI: Reserve legacy mmio after PCI mmio sparc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing sparc/PCI: Keep resource idx order with bridge register number powerpc/PCI: Keep resource idx order with bridge register number powerpc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing OF/PCI: Add IORESOURCE_MEM_64 for 64-bit resource PCI: Check pref compatible bit for mem64 resource of PCIe device PCI: Only treat non-pref mmio64 as pref if all bridges have MEM_64 PCI: Add has_mem64 for struct host_bridge PCI: Only treat non-pref mmio64 as pref if host bridge has mmio64 PCI: Restore pref MMIO allocation logic for host bridge without mmio64 arch/microblaze/pci/pci-common.c | 74 ++--- arch/powerpc/kernel/pci-common.c | 74 ++--- arch/powerpc/kernel/pci_of_scan.c | 12 +++- arch/sparc/kernel/of_device_32.c | 5 +- arch/sparc/kernel/of_device_64.c | 5 +- arch/sparc/kernel/pci.c | 132 -- arch/sparc/kernel/pci_common.c| 91 +++--- arch/sparc/kernel/pci_impl.h | 5 ++ arch/xtensa/kernel/pci.c | 75 +++--- drivers/of/address.c | 4 +- drivers/pci/bus.c | 4 +- drivers/pci/pci-sysfs.c | 33 +++--- drivers/pci/pci.c | 31 + drivers/pci/pci.h | 4 +- drivers/pci/probe.c | 40 drivers/pci/proc.c| 60 ++--- drivers/pci/setup-bus.c | 65 --- drivers/pci/setup-res.c | 13 +++- include/linux/pci.h | 4 ++ 19 files changed, 325 insertions(+), 406 deletions(-) -- 2.8.3
[PATCH v13 12/16] PCI: Check pref compatible bit for mem64 resource of PCIe device
We still get "no compatible bridge window" warning on sparc T5-8
after we add support for 64bit resource parsing for root bus.
PCI: scan_bus[/pci@300/pci@1/pci@0/pci@6] bus no 8
PCI: Claiming :00:01.0: Resource 15: 8001..8004afff
[220c]
PCI: Claiming :01:00.0: Resource 15: 8001..8004afff
[220c]
PCI: Claiming :02:04.0: Resource 15: 8001..80012fff
[220c]
PCI: Claiming :03:00.0: Resource 15: 8001..80012fff
[220c]
PCI: Claiming :04:06.0: Resource 14: 8001..80010fff
[220c]
PCI: Claiming :05:00.0: Resource 0: 8001..80011fff
[204]
pci :05:00.0: can't claim BAR 0 [mem 0x8001-0x80011fff]: no
compatible bridge window
All the bridges 64-bit resource have pref bit, but the device resource does not
have pref set, then we can not find parent for the device resource,
as we can not put non-pref mmio under pref mmio.
According to pcie spec errta
https://www.pcisig.com/specifications/pciexpress/base2/PCIe_Base_r2.1_Errata_08Jun10.pdf
page 13, in some case it is ok to mark some as pref.
Mark if the entire path from the host to the adapter is over PCI Express.
Set pref compatible bit for claim/sizing/assign for 64bit mem resource
on that pcie device.
-v2: set pref for mmio 64 when whole path is PCI Express, according to David
Miller.
-v3: don't set pref directly, change to UNDER_PREF, and set PREF before
sizing and assign resource, and cleart PREF afterwards. requested by BenH.
-v4: use on_all_pcie_path device flag instead.
-v6: update after pci_find_bus_resource() change
Link:
http://lkml.kernel.org/r/cae9fiqu1gjy1lyrxs+ma5lcteee4xmtjrg0axj9k_tsu+m9...@mail.gmail.com
Reported-by: David Ahern
Tested-by: David Ahern
Link: https://bugzilla.kernel.org/show_bug.cgi?id=81431
Tested-by: TJ
Signed-off-by: Yinghai Lu
Tested-by: Khalid Aziz
Cc: sparcli...@vger.kernel.org
---
arch/sparc/kernel/pci_common.c | 2 +-
drivers/pci/pci.c | 8 +---
drivers/pci/pci.h | 2 ++
drivers/pci/probe.c| 33 +
drivers/pci/setup-bus.c| 23 +++
drivers/pci/setup-res.c| 4
include/linux/pci.h| 3 ++-
7 files changed, 66 insertions(+), 9 deletions(-)
diff --git a/arch/sparc/kernel/pci_common.c b/arch/sparc/kernel/pci_common.c
index 1ebc7ff..6f206a1 100644
--- a/arch/sparc/kernel/pci_common.c
+++ b/arch/sparc/kernel/pci_common.c
@@ -343,7 +343,7 @@ static void pci_register_region(struct pci_bus *bus, const
char *name,
region.start = rstart;
region.end = rstart + size - 1UL;
pcibios_bus_to_resource(bus, res, ®ion);
- bus_res = pci_find_bus_resource(bus, res);
+ bus_res = pci_find_bus_resource(bus, res, res->flags);
if (!bus_res) {
kfree(res);
return;
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index 81c6cf9..f4ad1e0 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -415,7 +415,7 @@ int pci_find_ht_capability(struct pci_dev *dev, int ht_cap)
EXPORT_SYMBOL_GPL(pci_find_ht_capability);
struct resource *pci_find_bus_resource(const struct pci_bus *bus,
- struct resource *res)
+ struct resource *res, int flags)
{
struct resource *r;
int i;
@@ -430,7 +430,7 @@ struct resource *pci_find_bus_resource(const struct pci_bus
*bus,
* not, the allocator made a mistake.
*/
if (r->flags & IORESOURCE_PREFETCH &&
- !(res->flags & IORESOURCE_PREFETCH))
+ !(flags & IORESOURCE_PREFETCH))
return NULL;
/*
@@ -458,7 +458,9 @@ struct resource *pci_find_bus_resource(const struct pci_bus
*bus,
struct resource *pci_find_parent_resource(const struct pci_dev *dev,
struct resource *res)
{
- return pci_find_bus_resource(dev->bus, res);
+ int flags = pci_resource_pref_compatible(dev, res);
+
+ return pci_find_bus_resource(dev->bus, res, flags);
}
EXPORT_SYMBOL(pci_find_parent_resource);
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 7d339c3..4508a1f 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -336,4 +336,6 @@ static inline int pci_dev_specific_reset(struct pci_dev
*dev, int probe)
}
#endif
+int pci_resource_pref_compatible(const struct pci_dev *dev,
+struct resource *res);
#endif /* DRIVERS_PCI_H */
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 8e3ef72..5d11dec 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1732,6 +1732,36 @@ static void pci_dma_configure(struct pci_dev *dev)
pci_put_host_bridge_device(bridge);
}
+static bool pci_up_pat
[PATCH v13 04/16] sparc/PCI: Use correct offset for bus address to resource
After we added 64bit mmio parsing, we got some "no compatible bridge window"
warning on anther new model that support 64bit resource.
It turns out that we can not use mem_space.start as 64bit mem space
offset, aka there is mem_space.start != offset.
Use child_phys_addr to calculate exact offset and record offset in
pbm.
After patch we get correct offset.
/pci@305: PCI IO [io 0x2007e-0x2007e0fff] offset 2007e
/pci@305: PCI MEM [mem 0x20010-0x27eff] offset 2
/pci@305: PCI MEM64 [mem 0x20001-0x2000d] offset 2
...
pci_sun4v f02ae7f8: PCI host bridge to bus :00
pci_bus :00: root bus resource [io 0x2007e-0x2007e0fff] (bus
address [0x-0xfff])
pci_bus :00: root bus resource [mem 0x20010-0x27eff] (bus
address [0x0010-0x7eff])
pci_bus :00: root bus resource [mem 0x20001-0x2000d] (bus
address [0x1-0xd])
-v3: put back mem64_offset, as we found T4 has mem_offset != mem64_offset
check overlapping between mem64_space and mem_space.
-v7: after new pci_mmap_page_range patches.
-v8: remove change in pci_resource_to_user()
Signed-off-by: Yinghai Lu
Tested-by: Khalid Aziz
Cc: sparcli...@vger.kernel.org
---
arch/sparc/kernel/pci.c| 6 +++---
arch/sparc/kernel/pci_common.c | 32
arch/sparc/kernel/pci_impl.h | 4
3 files changed, 31 insertions(+), 11 deletions(-)
diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index c7d2ce6..e16da35 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -663,12 +663,12 @@ struct pci_bus *pci_scan_one_pbm(struct pci_pbm_info *pbm,
printk("PCI: Scanning PBM %s\n", node->full_name);
pci_add_resource_offset(&resources, &pbm->io_space,
- pbm->io_space.start);
+ pbm->io_offset);
pci_add_resource_offset(&resources, &pbm->mem_space,
- pbm->mem_space.start);
+ pbm->mem_offset);
if (pbm->mem64_space.flags)
pci_add_resource_offset(&resources, &pbm->mem64_space,
- pbm->mem_space.start);
+ pbm->mem64_offset);
pbm->busn.start = pbm->pci_first_busno;
pbm->busn.end = pbm->pci_last_busno;
pbm->busn.flags = IORESOURCE_BUS;
diff --git a/arch/sparc/kernel/pci_common.c b/arch/sparc/kernel/pci_common.c
index 33524c1..76998f8 100644
--- a/arch/sparc/kernel/pci_common.c
+++ b/arch/sparc/kernel/pci_common.c
@@ -410,13 +410,16 @@ void pci_determine_mem_io_space(struct pci_pbm_info *pbm)
for (i = 0; i < num_pbm_ranges; i++) {
const struct linux_prom_pci_ranges *pr = &pbm_ranges[i];
- unsigned long a, size;
+ unsigned long a, size, region_a;
u32 parent_phys_hi, parent_phys_lo;
+ u32 child_phys_mid, child_phys_lo;
u32 size_hi, size_lo;
int type;
parent_phys_hi = pr->parent_phys_hi;
parent_phys_lo = pr->parent_phys_lo;
+ child_phys_mid = pr->child_phys_mid;
+ child_phys_lo = pr->child_phys_lo;
if (tlb_type == hypervisor)
parent_phys_hi &= 0x0fff;
@@ -426,6 +429,8 @@ void pci_determine_mem_io_space(struct pci_pbm_info *pbm)
type = (pr->child_phys_hi >> 24) & 0x3;
a = (((unsigned long)parent_phys_hi << 32UL) |
((unsigned long)parent_phys_lo << 0UL));
+ region_a = (((unsigned long)child_phys_mid << 32UL) |
+((unsigned long)child_phys_lo << 0UL));
size = (((unsigned long)size_hi << 32UL) |
((unsigned long)size_lo << 0UL));
@@ -440,6 +445,7 @@ void pci_determine_mem_io_space(struct pci_pbm_info *pbm)
pbm->io_space.start = a;
pbm->io_space.end = a + size - 1UL;
pbm->io_space.flags = IORESOURCE_IO;
+ pbm->io_offset = a - region_a;
saw_io = 1;
break;
@@ -448,6 +454,7 @@ void pci_determine_mem_io_space(struct pci_pbm_info *pbm)
pbm->mem_space.start = a;
pbm->mem_space.end = a + size - 1UL;
pbm->mem_space.flags = IORESOURCE_MEM;
+ pbm->mem_offset = a - region_a;
saw_mem = 1;
break;
@@ -456,6 +463,7 @@ void pci_determine_mem_io_space(struct pci_pbm_info *pbm)
pbm->mem64_space.start = a;
pbm->mem64_space.end = a + size - 1UL;
pbm->mem64_space.flags = IORESOURCE_MEM;
+ pbm->mem64_o
[PATCH v13 01/16] PCI: Let pci_mmap_page_range() take resource address
In 8c05cd08a7 ("PCI: fix offset check for sysfs mmapped files"), try
to check exposed value with resource start/end in proc mmap path.
|start = vma->vm_pgoff;
|size = ((pci_resource_len(pdev, resno) - 1) >> PAGE_SHIFT) + 1;
|pci_start = (mmap_api == PCI_MMAP_PROCFS) ?
|pci_resource_start(pdev, resno) >> PAGE_SHIFT : 0;
|if (start >= pci_start && start < pci_start + size &&
|start + nr <= pci_start + size)
That breaks sparc that exposed value is BAR value, and need to be offseted
to resource address.
Original pci_mmap_page_range() is taking PCI BAR value aka usr_address.
Bjorn found out that it would be much simple to pass resource address
directly and avoid extra those __pci_mmap_make_offset.
In this patch:
1. in proc path: proc_bus_pci_mmap, try convert back to resource
before calling pci_mmap_page_range
2. in sysfs path: pci_mmap_resource will just offset with resource start.
3. all pci_mmap_page_range will have vma->vm_pgoff with in resource
range instead of BAR value.
4. skip calling __pci_mmap_make_offset, as the checking is done
in pci_mmap_fits().
-v2: add pci_user_to_resource and remove __pci_mmap_make_offset
-v3: pass resource pointer with pci_mmap_page_range()
-v4: put __pci_mmap_make_offset() removing to following patch
seperate /sys io access alignment checking to another patch
updated after Bjorn's pci_resource_to_user() changes.
Signed-off-by: Yinghai Lu
Cc: linuxppc-...@lists.ozlabs.org
Cc: sparcli...@vger.kernel.org
Cc: linux-xte...@linux-xtensa.org
---
arch/microblaze/pci/pci-common.c | 11 +---
arch/powerpc/kernel/pci-common.c | 11 +---
arch/sparc/kernel/pci.c | 4 ---
arch/xtensa/kernel/pci.c | 13 +++--
drivers/pci/pci-sysfs.c | 23 +--
drivers/pci/pci.h| 2 +-
drivers/pci/proc.c | 60 ++--
7 files changed, 91 insertions(+), 33 deletions(-)
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index 81556b8..9e3bc05 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -282,12 +282,15 @@ int pci_mmap_page_range(struct pci_dev *dev, struct
vm_area_struct *vma,
{
resource_size_t offset =
((resource_size_t)vma->vm_pgoff) << PAGE_SHIFT;
- struct resource *rp;
int ret;
- rp = __pci_mmap_make_offset(dev, &offset, mmap_state);
- if (rp == NULL)
- return -EINVAL;
+ if (mmap_state == pci_mmap_io) {
+ struct pci_controller *hose = pci_bus_to_host(dev->bus);
+
+ /* hose should never be NULL */
+ offset += hose->io_base_phys -
+((unsigned long)hose->io_base_virt - _IO_BASE);
+ }
vma->vm_pgoff = offset >> PAGE_SHIFT;
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 6de6e0e..53ba098 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -420,12 +420,15 @@ int pci_mmap_page_range(struct pci_dev *dev, struct
vm_area_struct *vma,
{
resource_size_t offset =
((resource_size_t)vma->vm_pgoff) << PAGE_SHIFT;
- struct resource *rp;
int ret;
- rp = __pci_mmap_make_offset(dev, &offset, mmap_state);
- if (rp == NULL)
- return -EINVAL;
+ if (mmap_state == pci_mmap_io) {
+ struct pci_controller *hose = pci_bus_to_host(dev->bus);
+
+ /* hose should never be NULL */
+ offset += hose->io_base_phys -
+ ((unsigned long)hose->io_base_virt - _IO_BASE);
+ }
vma->vm_pgoff = offset >> PAGE_SHIFT;
if (write_combine)
diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index 9c1878f..5f2d78e 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -868,10 +868,6 @@ int pci_mmap_page_range(struct pci_dev *dev, struct
vm_area_struct *vma,
{
int ret;
- ret = __pci_mmap_make_offset(dev, vma, mmap_state);
- if (ret < 0)
- return ret;
-
__pci_mmap_set_pgprot(dev, vma, mmap_state);
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
diff --git a/arch/xtensa/kernel/pci.c b/arch/xtensa/kernel/pci.c
index b848cc3..4c5f1fa 100644
--- a/arch/xtensa/kernel/pci.c
+++ b/arch/xtensa/kernel/pci.c
@@ -366,11 +366,18 @@ int pci_mmap_page_range(struct pci_dev *dev, struct
vm_area_struct *vma,
enum pci_mmap_state mmap_state,
int write_combine)
{
+ unsigned long offset = vma->vm_pgoff << PAGE_SHIFT;
int ret;
- ret = __pci_mmap_make_offset(dev, vma, mmap_state);
- if (ret < 0)
- return ret;
+ if (mmap_state == pci_mmap_io) {
+
Re: [PATCH v12.update2 02/15] PCI: Let pci_mmap_page_range() take resource address
On Fri, Jun 17, 2016 at 12:52 PM, Bjorn Helgaas wrote: >> >> and respin the whole patchset today. > > I added your acks and pushed the result to pci/resource. I'll also > post these formally on the list so they're easier to find. Please review patchset v13 that is against your new pci/resource branch. Thanks Yinghai
[PATCH v13 02/16] PCI: Remove __pci_mmap_make_offset()
After
PCI: Let pci_mmap_page_range() take resource address
No user for __pci_mmap_make_offset in those arch.
Remove them.
Signed-off-by: Yinghai Lu
Cc: linuxppc-...@lists.ozlabs.org
Cc: sparcli...@vger.kernel.org
Cc: linux-xte...@linux-xtensa.org
---
arch/microblaze/pci/pci-common.c | 63 --
arch/powerpc/kernel/pci-common.c | 63 --
arch/sparc/kernel/pci.c | 113 ---
arch/xtensa/kernel/pci.c | 62 -
4 files changed, 301 deletions(-)
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index 9e3bc05..e7cd0ab 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -156,69 +156,6 @@ void pcibios_set_master(struct pci_dev *dev)
*/
/*
- * Adjust vm_pgoff of VMA such that it is the physical page offset
- * corresponding to the 32-bit pci bus offset for DEV requested by the user.
- *
- * Basically, the user finds the base address for his device which he wishes
- * to mmap. They read the 32-bit value from the config space base register,
- * add whatever PAGE_SIZE multiple offset they wish, and feed this into the
- * offset parameter of mmap on /proc/bus/pci/XXX for that device.
- *
- * Returns negative error code on failure, zero on success.
- */
-static struct resource *__pci_mmap_make_offset(struct pci_dev *dev,
- resource_size_t *offset,
- enum pci_mmap_state mmap_state)
-{
- struct pci_controller *hose = pci_bus_to_host(dev->bus);
- unsigned long io_offset = 0;
- int i, res_bit;
-
- if (!hose)
- return NULL;/* should never happen */
-
- /* If memory, add on the PCI bridge address offset */
- if (mmap_state == pci_mmap_mem) {
-#if 0 /* See comment in pci_resource_to_user() for why this is disabled */
- *offset += hose->pci_mem_offset;
-#endif
- res_bit = IORESOURCE_MEM;
- } else {
- io_offset = (unsigned long)hose->io_base_virt - _IO_BASE;
- *offset += io_offset;
- res_bit = IORESOURCE_IO;
- }
-
- /*
-* Check that the offset requested corresponds to one of the
-* resources of the device.
-*/
- for (i = 0; i <= PCI_ROM_RESOURCE; i++) {
- struct resource *rp = &dev->resource[i];
- int flags = rp->flags;
-
- /* treat ROM as memory (should be already) */
- if (i == PCI_ROM_RESOURCE)
- flags |= IORESOURCE_MEM;
-
- /* Active and same type? */
- if ((flags & res_bit) == 0)
- continue;
-
- /* In the range of this resource? */
- if (*offset < (rp->start & PAGE_MASK) || *offset > rp->end)
- continue;
-
- /* found it! construct the final physical address */
- if (mmap_state == pci_mmap_io)
- *offset += hose->io_base_phys - io_offset;
- return rp;
- }
-
- return NULL;
-}
-
-/*
* This one is used by /dev/mem and fbdev who have no clue about the
* PCI device, it tries to find the PCI device first and calls the
* above routine
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index 53ba098..14c183d 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -293,69 +293,6 @@ static int pci_read_irq_line(struct pci_dev *pci_dev)
*/
/*
- * Adjust vm_pgoff of VMA such that it is the physical page offset
- * corresponding to the 32-bit pci bus offset for DEV requested by the user.
- *
- * Basically, the user finds the base address for his device which he wishes
- * to mmap. They read the 32-bit value from the config space base register,
- * add whatever PAGE_SIZE multiple offset they wish, and feed this into the
- * offset parameter of mmap on /proc/bus/pci/XXX for that device.
- *
- * Returns negative error code on failure, zero on success.
- */
-static struct resource *__pci_mmap_make_offset(struct pci_dev *dev,
- resource_size_t *offset,
- enum pci_mmap_state mmap_state)
-{
- struct pci_controller *hose = pci_bus_to_host(dev->bus);
- unsigned long io_offset = 0;
- int i, res_bit;
-
- if (hose == NULL)
- return NULL;/* should never happen */
-
- /* If memory, add on the PCI bridge address offset */
- if (mmap_state == pci_mmap_mem) {
-#if 0 /* See comment in pci_resource_to_user() for why this is disabled */
- *offset += hose->pci_mem_offset;
-#endif
- res_bit = IORESOURCE_MEM;
- } else {
- io_offset = (unsigned long)hose->io_base_virt - _IO_BASE;
-
[PATCH v13 11/16] OF/PCI: Add IORESOURCE_MEM_64 for 64-bit resource
For device resource PREF bit setting under bridge 64-bit pref resource, we need to make sure only set PREF for 64bit resource. This patch set IORESOUCE_MEM_64 for 64bit resource during OF device resource flags parsing. Link: https://bugzilla.kernel.org/show_bug.cgi?id=96261 Link: https://bugzilla.kernel.org/show_bug.cgi?id=96241 Signed-off-by: Yinghai Lu Cc: Grant Likely Cc: Rob Herring Cc: devicet...@vger.kernel.org Tested-by: Khalid Aziz --- drivers/of/address.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/of/address.c b/drivers/of/address.c index 0a553c0..fa10b99 100644 --- a/drivers/of/address.c +++ b/drivers/of/address.c @@ -129,9 +129,11 @@ static unsigned int of_bus_pci_get_flags(const __be32 *addr) flags |= IORESOURCE_IO; break; case 0x02: /* 32 bits */ - case 0x03: /* 64 bits */ flags |= IORESOURCE_MEM; break; + case 0x03: /* 64 bits */ + flags |= IORESOURCE_MEM | IORESOURCE_MEM_64; + break; } if (w & 0x4000) flags |= IORESOURCE_PREFETCH; -- 2.8.3
[PATCH v13 10/16] powerpc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing
For device resource PREF bit setting under bridge 64-bit pref resource,
we need to make sure only set PREF for 64bit resource.
This patch set IORESOUCE_MEM_64 for 64bit resource during OF device resource
flags parsing.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96261
Link: https://bugzilla.kernel.org/show_bug.cgi?id=96241
Signed-off-by: Yinghai Lu
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Gavin Shan
Cc: Yijing Wang
Cc: Anton Blanchard
Cc: linuxppc-...@lists.ozlabs.org
---
arch/powerpc/kernel/pci_of_scan.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/pci_of_scan.c
b/arch/powerpc/kernel/pci_of_scan.c
index 719f225..476b8ac5 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -44,8 +44,10 @@ static unsigned int pci_parse_of_flags(u32 addr0, int bridge)
if (addr0 & 0x0200) {
flags = IORESOURCE_MEM | PCI_BASE_ADDRESS_SPACE_MEMORY;
- flags |= (addr0 >> 22) & PCI_BASE_ADDRESS_MEM_TYPE_64;
flags |= (addr0 >> 28) & PCI_BASE_ADDRESS_MEM_TYPE_1M;
+ if (addr0 & 0x0100)
+ flags |= IORESOURCE_MEM_64
+| PCI_BASE_ADDRESS_MEM_TYPE_64;
if (addr0 & 0x4000)
flags |= IORESOURCE_PREFETCH
| PCI_BASE_ADDRESS_MEM_PREFETCH;
--
2.8.3
[PATCH v13 08/16] sparc/PCI: Keep resource idx order with bridge register number
On one system found strange "no compatible bridge window" warning
even we already had pref_compat support that add extra pref bit for device
resource.
PCI: Claiming :00:01.0: Resource 14: 00020001..000200010fff
[10220c]
PCI: Claiming :01:00.0: Resource 1: 00020001..00020001
[100214]
pci :01:00.0: can't claim BAR 1 [mem 0x20001-0x20001
64bit]: no compatible bridge window
It turns out that pci_resource_compatible()/pci_up_path_over_pref_mem64()
just check resource with bridge pref mmio register idx 15, and we have put
resource to use mmio register idx 14 during of_scan_pci_bridge()
as the bridge does not have mmio resource.
We already fix pci_up_path_over_pref_mem64() to check all bus resources.
And at the same time, this patch make resource to have consistent sequence
like other arch or directly from pci_read_bridge_bases(),
even when non-pref mmio is missing, or out of ordering in firmware reporting.
Just hold i = 1 for non pref mmio, and i = 2 for pref mmio.
Signed-off-by: Yinghai Lu
Tested-by: Khalid Aziz
Cc: sparcli...@vger.kernel.org
---
arch/sparc/kernel/pci.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index 654cf21..c6a3971 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -481,7 +481,7 @@ static void of_scan_pci_bridge(struct pci_pbm_info *pbm,
pci_read_bridge_bases(bus);
goto after_ranges;
}
- i = 1;
+ i = 3;
for (; len >= 32; len -= 32, ranges += 8) {
u64 start;
@@ -513,6 +513,12 @@ static void of_scan_pci_bridge(struct pci_pbm_info *pbm,
" for bridge %s\n", node->full_name);
continue;
}
+ } else if ((flags & IORESOURCE_PREFETCH) &&
+ !bus->resource[2]->flags) {
+ res = bus->resource[2];
+ } else if (((flags & (IORESOURCE_MEM | IORESOURCE_PREFETCH)) ==
+ IORESOURCE_MEM) && !bus->resource[1]->flags) {
+ res = bus->resource[1];
} else {
if (i >= PCI_NUM_RESOURCES - PCI_BRIDGE_RESOURCES) {
printk(KERN_ERR "PCI: too many memory ranges"
--
2.8.3
[PATCH v13 07/16] sparc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing
For device resource with PREF bit setting under bridge 64-bit pref resource, we need to make sure only set PREF for 64bit resource. so this patch set IORESOUCE_MEM_64 for 64bit resource during OF device resource flags parsing. Link: https://bugzilla.kernel.org/show_bug.cgi?id=96261 Link: https://bugzilla.kernel.org/show_bug.cgi?id=96241 Signed-off-by: Yinghai Lu Cc: "David S. Miller" Cc: sparcli...@vger.kernel.org Tested-by: Khalid Aziz --- arch/sparc/kernel/of_device_32.c | 5 +++-- arch/sparc/kernel/of_device_64.c | 5 +++-- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/arch/sparc/kernel/of_device_32.c b/arch/sparc/kernel/of_device_32.c index 185aa96..3e9f273 100644 --- a/arch/sparc/kernel/of_device_32.c +++ b/arch/sparc/kernel/of_device_32.c @@ -83,11 +83,12 @@ static unsigned long of_bus_pci_get_flags(const u32 *addr, unsigned long flags) case 0x01: flags |= IORESOURCE_IO; break; - case 0x02: /* 32 bits */ - case 0x03: /* 64 bits */ flags |= IORESOURCE_MEM; break; + case 0x03: /* 64 bits */ + flags |= IORESOURCE_MEM | IORESOURCE_MEM_64; + break; } if (w & 0x4000) flags |= IORESOURCE_PREFETCH; diff --git a/arch/sparc/kernel/of_device_64.c b/arch/sparc/kernel/of_device_64.c index 7bbdc26..defee61 100644 --- a/arch/sparc/kernel/of_device_64.c +++ b/arch/sparc/kernel/of_device_64.c @@ -146,11 +146,12 @@ static unsigned long of_bus_pci_get_flags(const u32 *addr, unsigned long flags) case 0x01: flags |= IORESOURCE_IO; break; - case 0x02: /* 32 bits */ - case 0x03: /* 64 bits */ flags |= IORESOURCE_MEM; break; + case 0x03: /* 64 bits */ + flags |= IORESOURCE_MEM | IORESOURCE_MEM_64; + break; } if (w & 0x4000) flags |= IORESOURCE_PREFETCH; -- 2.8.3
[PATCH v13 03/16] PCI: Check resource alignment for /sys pci_mmap_resource path
When user access /sys/.../resourceX with pci_mmap_resource(),
pci_mmap_resource():
...
pci_resource_to_user(pdev, i, res, &start, &end);
vma->vm_pgoff += start >> PAGE_SHIFT;
mmap_type = res->flags & IORESOURCE_MEM ? pci_mmap_mem : pci_mmap_io;
return pci_mmap_page_range(pdev, vma, mmap_type, write_combine);
so it will return virtual address for round_down of start.
user code should pass offset with PAGE_SIZE offset.
fd = open(argv[1], O_RDONLY);
...
sscanf(argv[2], "0x%lx", &offset);
left = offset & (PAGE_SIZE - 1);
offset &= PAGE_MASK;
addr = mmap(NULL, PAGE_SIZE, PROT_READ, MAP_SHARED, fd, offset);
for (i = 0; i < 8; i++)
printf("%x ", addr[i + left]);
munmap(addr, PAGE_SIZE);
close(fd);
When the resource start is not PAGE_SIZE aligned, it should
be io port, pci_mmap_resource could return round_down address of
resource start.
As the whole point for pci_mmap_resource is passing offset in
[0, resource_size), user may assume virtual add is corresponding
to unaligned resource_size. Later they could get wrong value
with offset to resource start.
Block the path for now, and need to use pci_read_resource_io
/pci_write_resource_io path instead.
user code should be like:
fd = open(argv[1], O_RDONLY);
...
sscanf(argv[2], "0x%lx", &offset);
for (i = 0; i < 8; i++) {
pread(fd, &buf, 1, i + offset);
}
close(fd);
Signed-off-by: Yinghai Lu
---
drivers/pci/pci-sysfs.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 82b98dd..138dfc2 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -1018,6 +1018,16 @@ static int pci_mmap_resource(struct kobject *kobj,
struct bin_attribute *attr,
if (i >= PCI_ROM_RESOURCE)
return -ENODEV;
+ /*
+* resource start have to be PAGE_SIZE aligned, as we pass
+* back virt address include round down of resource_start,
+* that caller can not figure out directly.
+* when it is not aligned, that mean it is io port, should go
+* pci_read_resource_io()/pci_write_resource_io() path.
+*/
+ if (res->start & ~PAGE_MASK)
+ return -EINVAL;
+
if (res->flags & IORESOURCE_MEM && iomem_is_exclusive(res->start))
return -EINVAL;
--
2.8.3
[PATCH] ASoC: cs53l30: Set idle_bias_off true
The driver is using the set_bias_level to control the power on and
off so it should get SND_SOC_BIAS_OFF in order to proceed normal
powering sequences. This patch enables the idle_bias_off option so
the DAPM core will set the bias level to SND_SOC_BIAS_OFF instead
of stopping at SND_SOC_BIAS_STANDBY.
Signed-off-by: Nicolin Chen
---
sound/soc/codecs/cs53l30.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/codecs/cs53l30.c b/sound/soc/codecs/cs53l30.c
index a5976f3..b0a64a1 100644
--- a/sound/soc/codecs/cs53l30.c
+++ b/sound/soc/codecs/cs53l30.c
@@ -879,6 +879,7 @@ static int cs53l30_codec_probe(struct snd_soc_codec *codec)
static struct snd_soc_codec_driver cs53l30_driver = {
.probe = cs53l30_codec_probe,
.set_bias_level = cs53l30_set_bias_level,
+ .idle_bias_off = true,
.dapm_widgets = cs53l30_dapm_widgets,
.num_dapm_widgets = ARRAY_SIZE(cs53l30_dapm_widgets),
--
2.1.4
Re: [PATCH -next] drm/hisilicon: Fix return value check in ade_dts_parse()
Thanks!
On 2016/6/18 2:29, weiyj...@163.com wrote:
> From: Wei Yongjun
>
> In case of error, the function devm_clk_get() returns ERR_PTR()
> and never returns NULL. The NULL test in the return value check
> should be replaced with IS_ERR().
>
> Signed-off-by: Wei Yongjun
Reviewed-by: Chen Feng
> ---
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> index ed76baad..16834f4 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c
> @@ -965,21 +965,21 @@ static int ade_dts_parse(struct platform_device *pdev,
> struct ade_hw_ctx *ctx)
> }
>
> ctx->ade_core_clk = devm_clk_get(dev, "clk_ade_core");
> - if (!ctx->ade_core_clk) {
> + if (IS_ERR(ctx->ade_core_clk)) {
> DRM_ERROR("failed to parse clk ADE_CORE\n");
> - return -ENODEV;
> + return PTR_ERR(ctx->ade_core_clk);
> }
>
> ctx->media_noc_clk = devm_clk_get(dev, "clk_codec_jpeg");
> - if (!ctx->media_noc_clk) {
> + if (IS_ERR(ctx->media_noc_clk)) {
> DRM_ERROR("failed to parse clk CODEC_JPEG\n");
> - return -ENODEV;
> + return PTR_ERR(ctx->media_noc_clk);
> }
>
> ctx->ade_pix_clk = devm_clk_get(dev, "clk_ade_pix");
> - if (!ctx->ade_pix_clk) {
> + if (IS_ERR(ctx->ade_pix_clk)) {
> DRM_ERROR("failed to parse clk ADE_PIX\n");
> - return -ENODEV;
> + return PTR_ERR(ctx->ade_pix_clk);
> }
>
> return 0;
>
>
>
>
>
>
> .
>
Re: [PATCH v2 4/8] scripts: add glimpse.sh for indexing the kernel
On Fri, Jun 17, 2016 at 05:35:26PM +0200, Julia Lawall wrote: > On Fri, 17 Jun 2016, Luis R. Rodriguez wrote: > > > On Fri, Jun 17, 2016 at 11:44:26AM +0200, Julia Lawall wrote: > > > I'm not sure that this is worth it. It adds a dependency on a tool that > > > seems not to be well maintained. In terms of Coccinelle, I'm not sure > > > that it gives a big benefit. > > > > > > Attached is a graph showing the file selection time for Coccinelle for a > > > selection of fairly complex semantic patches. Coccigrep is just a > > > line-by-line regexp search implemented in ocaml, gitgrep uses git grep. > > > In most cases, glimpse is clearly faster. > > > > > > On the other hand, it seems that glimpse often selects more files. > > > Sometimes a few more, eg 16 vs 14, and sometimes quite a lot more, eg 538 > > > vs 236. I suspect that this is because glimpse considers _ to be a space, > > > and thus it can have many false positives. There are, however, a few > > > cases where glimpse also selects fewer files. > > > > > > The file processing time (ie parsing the file, searching for, matches of > > > the semantic patch in the file, and performing the transformation) is > > > normally much higher than the file selection time. > > > > > > So it seems that git grep is currently a better option for the kernel. > > > > Great, thanks, consider this patch dropped, do we want the heuristics > > for the cache index in place though or should I drop that as well ? > > I assume you mean this patch: > > [PATCH v2 3/8] coccicheck: add indexing enhancement options > > I think it should be dropped. It adds complexity and git grep works > pretty well. Hmm but coccicheck does not make use of --git-grep even. > If people want to use something else, they can use SPARGS, > or a .cocciconfig file, eg: > > [spatch] > options = --use-glimpse Neat will these be used last and thus override anything? If so, what about just adding an upstream .cocciconfig with --use-gitgrep -- only issue then is what if a user wants to use idutils ? How do we let them override? Luis
Re: ktime_get_ts64() splat during resume
On Fri, Jun 17, 2016 at 11:03 PM, Rafael J. Wysocki wrote: > On Fri, Jun 17, 2016 at 6:12 PM, Borislav Petkov wrote: >> On Fri, Jun 17, 2016 at 05:28:10PM +0200, Rafael J. Wysocki wrote: >>> A couple of questions: >>> - I guess this is reproducible 100% of the time? >> >> Yap. >> >> I took latest Linus + tip/master which has your commit. >> >>> - If you do "echo disk > /sys/power/state" instead of using s2disk, >>> does it still crash in the same way? >> >> My suspend to disk script does: >> >> echo 3 > /proc/sys/vm/drop_caches >> echo "shutdown" > /sys/power/disk >> echo "disk" > /sys/power/state >> >> I don't use anything else for years now. >> >>> - Are both the image and boot kernels the same binary? >> >> Yep. > > OK, we need to find out what's wrong, then. > > First, please revert the changes in hibernate_asm_64.S alone and see > if that makes any difference. > > Hibernation should still work then most of the time, but the bug fixed > by this commit will be back. Due to the nature of the memory corruption you are seeing (the same address appears to be corrupted every time in the same way) with 100% reproducibility and due to the fact that new code added by the commit in question only writes to dynamically allocated memory (and you've already verified that https://patchwork.kernel.org/patch/9185165/ doesn't help), it is quite unlikely that the memory corruption comes from that commit itself. However, I see a couple of ways in which that commit might uncover a latent bug. First, it changed the layout of the kernel text by adding the PAGE_SIZE alignment of restore_registers(). That likely pushed stuff behind it to new offsets, possibly including the static struct field that is now corrupted. Now, say that the memory corruption has always happened at the same memory location, but previously there was nothing in there or whatever was in there, wasn't vital. In that case the memory corruption might have gone unnoticed until the commit in question caused things to move to new locations and the corrupted location contains a vital piece of data now. This is my current theory. Second, it added two invocations of get_safe_page() that in theory might push things a bit too far towards the limit and they started to break there. I don't see how that can happen ATM, but I'm not excluding this possibility yet. It seems, though, that in that case the corruption would be more random and I certainly wouldn't expect it to happen at the same location every time. One more indicator is that multiple people reported success with that commit and in many hibernation runs, so the problem appears to be very specific to your system and/or kernel configuration. It also is interesting that the memory corruption only becomes visible during the thawing of tasks and given the piece of data that is corrupted, it should become visible much earlier if the memory was corrupted during image restoration by the boot kernel. In any case, reverting the changes in hibernate_asm_64.S alone should show us the direction, but if it makes things work again, I would try to change the restore_registers() alignment to something smaller, like 64 (which should be safe) and see what happens then.
Re: [v3,1/4] mfd: cros_ec: Add cros_ec_cmd_xfer_status helper
On Fri, Jun 17, 2016 at 02:41:51PM -0700, Guenter Roeck wrote:
> On Fri, Jun 17, 2016 at 12:58:12PM -0700, Brian Norris wrote:
> > +int cros_ec_cmd_xfer_status(struct cros_ec_device *ec_dev,
> > + struct cros_ec_command *msg)
> > +{
> > + int ret;
> > +
> > + ret = cros_ec_cmd_xfer(ec_dev, msg);
> > + if (ret < 0)
> > + dev_err(ec_dev->dev, "Command xfer error (err:%d)\n", ret);
> > + else if (msg->result != EC_RES_SUCCESS)
> > + return -EECRESULT - msg->result;
>
> I have been wondering about the error return codes here, and if they should be
> converted to standard Linux error codes. For example, I just hit error -1003
> with a driver I am working on. This translates to EC_RES_INVALID_PARAM, or,
> in Linux terms, -EINVAL. I think it would be better to use standard error
> codes, especially since some of the errors are logged.
How do you propose we do that? Do all of the following become EINVAL?
EC_RES_INVALID_COMMAND
EC_RES_INVALID_PARAM
EC_RES_INVALID_VERSION
EC_RES_INVALID_HEADER
We lose a lot of information that way. And particularly, cros_ec_num_pwms()
won't be able to count as accurately. But I can just go back to not using this
API if that's what you'd like...
Brian
[PATCH 3/3] f2fs: avoid latency-critical readahead of node pages
The f2fs_map_blocks is very related to the performance, so let's avoid any
latency to read ahead node pages.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/data.c | 2 +-
fs/f2fs/file.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 0832528..ba4963f 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -652,7 +652,7 @@ int f2fs_map_blocks(struct inode *inode, struct
f2fs_map_blocks *map,
unsigned int maxblocks = map->m_len;
struct dnode_of_data dn;
struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
- int mode = create ? ALLOC_NODE : LOOKUP_NODE_RA;
+ int mode = create ? ALLOC_NODE : LOOKUP_NODE;
pgoff_t pgofs, end_offset, end;
int err = 0, ofs = 1;
unsigned int ofs_in_node, last_ofs_in_node;
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index f1f78fb..4e220ba 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -356,7 +356,7 @@ static loff_t f2fs_seek_block(struct file *file, loff_t
offset, int whence)
for (; data_ofs < isize; data_ofs = (loff_t)pgofs << PAGE_SHIFT) {
set_new_dnode(&dn, inode, NULL, NULL, 0);
- err = get_dnode_of_data(&dn, pgofs, LOOKUP_NODE_RA);
+ err = get_dnode_of_data(&dn, pgofs, LOOKUP_NODE);
if (err && err != -ENOENT) {
goto fail;
} else if (err == -ENOENT) {
--
2.8.3
[PATCH 1/3] f2fs: produce more nids and reduce readahead nats
The readahead nat pages are more likely to be reclaimed quickly, so it'd better
to gather more free nids in advance.
And, let's keep some free nids as much as possible.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/checkpoint.c | 2 ++
fs/f2fs/f2fs.h | 1 +
fs/f2fs/node.c | 9 ++---
fs/f2fs/node.h | 5 +++--
fs/f2fs/segment.c| 4 +++-
fs/f2fs/shrinker.c | 5 +++--
6 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 8534b98..2b43d40 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -941,6 +941,8 @@ out:
static void unblock_operations(struct f2fs_sb_info *sbi)
{
up_write(&sbi->node_write);
+
+ build_free_nids(sbi);
f2fs_unlock_all(sbi);
}
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 3019286..bd82b6d 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1985,6 +1985,7 @@ void move_node_page(struct page *, int);
int fsync_node_pages(struct f2fs_sb_info *, struct inode *,
struct writeback_control *, bool);
int sync_node_pages(struct f2fs_sb_info *, struct writeback_control *);
+void build_free_nids(struct f2fs_sb_info *);
bool alloc_nid(struct f2fs_sb_info *, nid_t *);
void alloc_nid_done(struct f2fs_sb_info *, nid_t);
void alloc_nid_failed(struct f2fs_sb_info *, nid_t);
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index b448c8f..729fb1e 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -1765,7 +1765,7 @@ static void scan_nat_page(struct f2fs_sb_info *sbi,
}
}
-static void build_free_nids(struct f2fs_sb_info *sbi)
+void build_free_nids(struct f2fs_sb_info *sbi)
{
struct f2fs_nm_info *nm_i = NM_I(sbi);
struct curseg_info *curseg = CURSEG_I(sbi, CURSEG_HOT_DATA);
@@ -1774,7 +1774,7 @@ static void build_free_nids(struct f2fs_sb_info *sbi)
nid_t nid = nm_i->next_scan_nid;
/* Enough entries */
- if (nm_i->fcnt > NAT_ENTRY_PER_BLOCK)
+ if (nm_i->fcnt >= NAT_ENTRY_PER_BLOCK)
return;
/* readahead nat pages to be scanned */
@@ -1912,12 +1912,15 @@ int try_to_free_nids(struct f2fs_sb_info *sbi, int
nr_shrink)
struct free_nid *i, *next;
int nr = nr_shrink;
+ if (nm_i->fcnt <= MAX_FREE_NIDS)
+ return 0;
+
if (!mutex_trylock(&nm_i->build_lock))
return 0;
spin_lock(&nm_i->free_nid_list_lock);
list_for_each_entry_safe(i, next, &nm_i->free_nid_list, list) {
- if (nr_shrink <= 0 || nm_i->fcnt <= NAT_ENTRY_PER_BLOCK)
+ if (nr_shrink <= 0 || nm_i->fcnt <= MAX_FREE_NIDS)
break;
if (i->state == NID_ALLOC)
continue;
diff --git a/fs/f2fs/node.h b/fs/f2fs/node.h
index 673ce92..fc76845 100644
--- a/fs/f2fs/node.h
+++ b/fs/f2fs/node.h
@@ -15,9 +15,10 @@
#defineNAT_BLOCK_OFFSET(start_nid) (start_nid / NAT_ENTRY_PER_BLOCK)
/* # of pages to perform synchronous readahead before building free nids */
-#define FREE_NID_PAGES 4
+#define FREE_NID_PAGES 8
+#define MAX_FREE_NIDS (NAT_ENTRY_PER_BLOCK * FREE_NID_PAGES)
-#define DEF_RA_NID_PAGES 4 /* # of nid pages to be readaheaded */
+#define DEF_RA_NID_PAGES 0 /* # of nid pages to be readaheaded */
/* maximum readahead size for node during getting data blocks */
#define MAX_RA_NODE128
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 782975e..6d16ecf 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -371,7 +371,9 @@ void f2fs_balance_fs_bg(struct f2fs_sb_info *sbi)
try_to_free_nats(sbi, NAT_ENTRY_PER_BLOCK);
if (!available_free_memory(sbi, FREE_NIDS))
- try_to_free_nids(sbi, NAT_ENTRY_PER_BLOCK * FREE_NID_PAGES);
+ try_to_free_nids(sbi, MAX_FREE_NIDS);
+ else
+ build_free_nids(sbi);
/* checkpoint is the only way to shrink partial cached entries */
if (!available_free_memory(sbi, NAT_ENTRIES) ||
diff --git a/fs/f2fs/shrinker.c b/fs/f2fs/shrinker.c
index 93606f2..46c9154 100644
--- a/fs/f2fs/shrinker.c
+++ b/fs/f2fs/shrinker.c
@@ -13,6 +13,7 @@
#include
#include "f2fs.h"
+#include "node.h"
static LIST_HEAD(f2fs_list);
static DEFINE_SPINLOCK(f2fs_list_lock);
@@ -25,8 +26,8 @@ static unsigned long __count_nat_entries(struct f2fs_sb_info
*sbi)
static unsigned long __count_free_nids(struct f2fs_sb_info *sbi)
{
- if (NM_I(sbi)->fcnt > NAT_ENTRY_PER_BLOCK)
- return NM_I(sbi)->fcnt - NAT_ENTRY_PER_BLOCK;
+ if (NM_I(sbi)->fcnt > MAX_FREE_NIDS)
+ return NM_I(sbi)->fcnt - MAX_FREE_NIDS;
return 0;
}
--
2.8.3
[PATCH 2/3] f2fs: avoid writing node/metapages during writes
Let's keep more node/meta pages in run time. Signed-off-by: Jaegeuk Kim --- fs/f2fs/segment.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h index d74cc33..57d450f 100644 --- a/fs/f2fs/segment.h +++ b/fs/f2fs/segment.h @@ -715,9 +715,9 @@ static inline int nr_pages_to_skip(struct f2fs_sb_info *sbi, int type) if (type == DATA) return sbi->blocks_per_seg; else if (type == NODE) - return 3 * sbi->blocks_per_seg; + return 8 * sbi->blocks_per_seg; else if (type == META) - return MAX_BIO_BLOCKS(sbi); + return 8 * MAX_BIO_BLOCKS(sbi); else return 0; } @@ -736,7 +736,7 @@ static inline long nr_pages_to_write(struct f2fs_sb_info *sbi, int type, nr_to_write = wbc->nr_to_write; if (type == NODE) - desired = 3 * max_hw_blocks(sbi); + desired = 2 * max_hw_blocks(sbi); else desired = MAX_BIO_BLOCKS(sbi); -- 2.8.3
Re: [PATCH v10 6/7] usb: pci-quirks: add Intel USB drcfg mux device
On Thu, Jun 16, 2016 at 08:27:41AM +0800, Lu Baolu wrote: > Hi Greg, > > On 06/09/2016 10:39 AM, Lu Baolu wrote: > > Hi Greg, > > > > On 06/08/2016 11:45 PM, Greg Kroah-Hartman wrote: > >> On Wed, Jun 08, 2016 at 03:56:04PM +0800, Lu Baolu wrote: > >>> Hi Greg, > >>> > >>> On 06/08/2016 12:45 PM, Greg Kroah-Hartman wrote: > On Thu, Jun 02, 2016 at 09:37:28AM +0800, Lu Baolu wrote: > > In some Intel platforms, a single usb port is shared between USB host > > and device controllers. The shared port is under control of a switch > > which is defined in the Intel vendor defined extended capability for > > xHCI. > > > > This patch adds the support to detect and create the platform device > > for the port mux switch. > Why do you need a platform device for this? You do nothing with this > device, why create it at all? > >>> In this patch series, I have a generic framework for port mux devices > >>> and two port mux drivers sitting on top the generic code. > >>> > >>> In this patch, I create a platform device for the real mux device in > >>> Intel Cherry Trail or Broxton SOCs. In it's driver, I registered a mux > >>> into the generic framework and handle the power management > >>> things in driver's pm entries (otherwise, the system can't be waken > >>> up from system suspend).:) > >>> > And why is it a platform device, isn't is really a PCI device? Why > would you ever find a "platform" device below a PCI device? Don't abuse > platform devices for things that aren't. It makes me want to delete > that whole interface more and more... > >>> Port mux devices are physical devices in Intel Cherry Trail and Broxton > >>> SOCs. It doesn't sit on any PCIe bus. But it maps its registers in xHCI > >>> space. OS kernel can enumerate it by looking up the xhci extended > >>> capability list with a vendor specific capability ID. > >> A physical device that maps registers into PCI space seems like a PCI > >> device of some type to me :) > >> > >> Again, I hate platform devices for obvious reasons like this... > >> > > It's not PCI configure space, but xhci's io memory. XHCI spec reserves > > a range in its extended capability list for vendor specific things. Intel's > > platform leverages this for the port mux device register mapping. > > It looks odd though. :) > > A gentle ping. :) For what? This patchset is long gone from my queue for the other various things that came up with it, what can I do with it now? > This port mux is not a PCI device. It only leverages the vendor > specific capability defined in xhci specification for enumeration. It's still crap :) I don't know, and don't really remember the patch anymore anyway, remember, I have the sort-term memory of a squirrel, you need repost patches, with a proper changelog for me to be able to do anything... greg k-h
Re: [kernel-hardening] [PATCH 2/2] security,perf: Allow further restriction of perf_event_open
On Fri, 2016-06-17 at 17:00 -0300, Arnaldo Carvalho de Melo wrote: > Em Fri, Jun 17, 2016 at 12:16:47PM -0400, Daniel Micay escreveu: > > On Fri, 2016-06-17 at 08:54 +0200, Peter Zijlstra wrote: > > > This Changelog is completely devoid of information. _WHY_ are you > > > doing this? > > > Attack surface reduction. It's possible to use seccomp-bpf for some > > limited cases, but it's not flexible enough. There are lots of > > information leaks and local privilege escalation vulnerabilities via > > perf events, yet on most Linux installs it's not ever being used. So > > turning it off by default on those installs is an easy win. The > > holes > > are reduced to root -> kernel (and that's not a meaningful boundary > > in > > mainline right now - although as is the case here, Debian has a > > bunch of > > securelevel patches for that). > > Is ptrace also disabled on such systems, or any of the other more > recent > syscalls? The same arguments could probably be used to disable those: > reduce attack surface, possibly the new ones have bugs as they are > relatively new and it takes a long time for new syscalls to be more > generally used, if we go on disabling them in such a way, they will > probably never get used :-\ ptrace is allowed for third party apps within their SELinux domain, but they all run as different users (so the kernel attack surface is there). It's now disabled for privileged platform apps and most other domains. A bit backwards, but removing it for third party apps would break compatibility so it would have to be done at an API level bump. At least, without deciding it is worth the cost like hidepid=2 in Android N (which exposes no mechanism for exceptions in 3rd party apps, only the base system). If seccomp-bpf didn't imply such high system call overhead outside of x86_64, Android would probably be walling off some new system calls. It needs 2-phase lookup similar to x86 on ARM. Android kernels do avoid enabling lots of kernel functionality from System V IPC to USERNS though. New features wouldn't end up enabled if they were behind config options without an explicit choice. > Wouldn't the recent bump in perf_event_paranoid to 2 enough? I.e. only > allow profiling of user tasks? Most of the vulnerabilities are still exposed at 2. That prevents leaking information about the kernel WITHOUT vulnerabilities though, and would be an improvement when perf is disabled - but that doesn't really matter much (Android kernel debugging and profiling would also still work with 2). > Or is there something more specific that we should disable/constrain > to > reduce such surface contact without using such a big hammer? It's desired to have it globally disabled by default. Could use seccomp- bpf to globally disable it, but that's a bigger hammer because it can't be globally turned off without a reboot (could only profile newly spawned processes after disabling it). Since it's only going to be enabled by developers, trying to make it more fine-grained wouldn't really pay off. signature.asc Description: This is a digitally signed message part
Re: [PATCH v2 0/8] firmware: add new sysdata API
On Sat, Jun 18, 2016 at 01:40:43AM +0200, Luis R. Rodriguez wrote: > On Thu, Jun 16, 2016 at 04:59:11PM -0700, Luis R. Rodriguez wrote: > > FWIW running it against linux-next next-20160616 on a 32-core system takes > > about 3 minutes using glimpse, also ~3 minutes with gitgrep and produces the > > following diffstat: > > > > 148 files changed, 5676 insertions(+), 4504 deletions(-) > > FWIW by using idutils the amount it takes is reduced considerably to 1 minute > for the entire kernel as well. Actually... even though idutils seems to be performing better Coccinelle 1.0.5 and even github version as of right now have an issue with idutils when these SmPL patches are used, so for now please use only gitgrep (default if you merge the pendign coccicheck enhancements if you are on a git tree with no ID or .id-utils.index from idutils). Luis
[GIT PULL] ACPI fix for v4.7-rc4
Hi Linus, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ acpi-4.7-rc4 to receive an ACPI update for v4.7-rc4 with top-most commit 46577e6a052ff5add7577ac748fb8628b3c3c7c9 Merge branch 'acpica-fixes' on top of commit 5edb56491d4812c42175980759da53388e5d86f5 Linux 4.7-rc3 Revert a recent ACPICA commit that introduced a suspend-to-RAM regression on one system due to incorrect information in its ACPI tables that had not been taken into consideration at all before (and everything worked), but the commit in question started to use it. Thanks! --- Rafael J. Wysocki (1): Revert "ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset support for acpi_hw_write()" --- drivers/acpi/acpica/hwregs.c | 146 +++ 1 file changed, 9 insertions(+), 137 deletions(-)
Re: [PATCH v6 2/2] drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel
Hi Vinay,
On 17 June 2016 at 19:23, Vinay Simha BN wrote:
> v6:
> * emil review comments incorporated
>PANEL_NUM_REGULATORS dropped, return ret added at necessary
>places, if checks dropped for backlight and gpios
Looks like some of my suggestions went below the radar. Did you miss
them or I've I lost the plot somewhere ? In case of the latter don't
be shy to point out :-)
> +struct jdi_panel {
> + struct drm_panel base;
> + struct mipi_dsi_device *dsi;
> +
> + struct regulator_bulk_data supplies[3];
> +
struct regulator_bulk_data supplies[ARRAY_SIZE(regulator_names)];
> +static int jdi_panel_off(struct jdi_panel *jdi)
> +{
> + struct mipi_dsi_device *dsi = jdi->dsi;
> + int ret;
> +
> + dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
> +
> + ret = mipi_dsi_dcs_set_display_off(dsi);
> + if (ret < 0)
> + return ret;
> +
IMHO neither this function nor its caller jdi_panel_unprepare() should
stop in the middle/return prematurely.
Or in other words - one should change the function return type to void
and drop the returns.
> +static int jdi_panel_unprepare(struct drm_panel *panel)
> +{
> + struct jdi_panel *jdi = to_jdi_panel(panel);
> + struct device *dev = &jdi->dsi->dev;
> + int ret;
> +
> + if (!jdi->prepared)
> + return 0;
> +
> + ret = jdi_panel_off(jdi);
> + if (ret) {
> + dev_err(panel->dev, "failed to set panel off: %d\n", ret);
> + return ret;
As suggested above, drop this return.
> +static int jdi_panel_prepare(struct drm_panel *panel)
> +{
> + struct jdi_panel *jdi = to_jdi_panel(panel);
> + struct device *dev = &jdi->dsi->dev;
> + int ret;
> +
> + if (jdi->prepared)
> + return 0;
> +
> + ret = regulator_bulk_enable(ARRAY_SIZE(jdi->supplies), jdi->supplies);
> + if (ret < 0) {
> + dev_err(dev, "regulator enable failed, %d\n", ret);
> + return ret;
> + }
> +
> + msleep(20);
> +
> + if (jdi->reset_gpio) {
You can drop the check.
> + gpiod_set_value(jdi->reset_gpio, 1);
> + usleep_range(10, 20);
> + }
> +
> + if (jdi->enable_gpio) {
Ditto.
> +
> +poweroff:
> + gpiod_set_value(jdi->enable_gpio, 0);
> + gpiod_set_value(jdi->reset_gpio, 0);
> +
Just noticed that you're missing regulator_bulk_disable() here.
Regards,
Emil
Re: [PATCH Documentation/memory-barriers.txt] Clarify limited control-dependency scope
On Fri, Jun 17, 2016 at 09:53:50AM +0200, Ingo Molnar wrote:
>
> * Paul E. McKenney wrote:
>
> > Nothing in the control-dependencies section of memory-barriers.txt
> > says that control dependencies don't extend beyond the end of the
> > if-statement containing the control dependency. Worse yet, in many
> > situations, they do extend beyond that if-statement. In particular,
> > the compiler cannot destroy the control dependency given proper use of
> > READ_ONCE() and WRITE_ONCE(). However, a weakly ordered system having
> > a conditional-move instruction provides the control-dependency guarantee
> > only to code within the scope of the if-statement itself.
> >
> > This commit therefore adds words and an example demonstrating this
> > limitation of control dependencies.
> >
> > Reported-by: Will Deacon
> > Signed-off-by: Paul E. McKenney
> > Acked-by: Peter Zijlstra (Intel)
> >
> > diff --git a/Documentation/memory-barriers.txt
> > b/Documentation/memory-barriers.txt
> > index 147ae8ec836f..a4d0a99de04d 100644
> > --- a/Documentation/memory-barriers.txt
> > +++ b/Documentation/memory-barriers.txt
> > @@ -806,6 +806,41 @@ out-guess your code. More generally, although
> > READ_ONCE() does force
> > the compiler to actually emit code for a given load, it does not force
> > the compiler to use the results.
> >
> > +In addition, control dependencies apply only to the then-clause and
> > +else-clause of the if-statement in question. In particular, it does
> > +not necessarily apply to code following the if-statement:
> > +
> > + q = READ_ONCE(a);
> > + if (q) {
> > + WRITE_ONCE(b, p);
> > + } else {
> > + WRITE_ONCE(b, r);
> > + }
> > + WRITE_ONCE(c, 1); /* BUG: No ordering against the read from "a". */
> > +
> > +It is tempting to argue that there in fact is ordering because the
> > +compiler cannot reorder volatile accesses and also cannot reorder
> > +the writes to "b" with the condition. Unfortunately for this line
> > +of reasoning, the compiler might compile the two writes to "b" as
> > +conditional-move instructions, as in this fanciful pseudo-assembly
> > +language:
>
> While CMOV would be the typical situation, even without CMOV the compiler
> could
> also internally transform it to:
>
> > + if (q)
> > + WRITE_ONCE(b, p);
> > + if (!q)
> > + WRITE_ONCE(b, r);
>
> ... and CPU speculation flow could get past the two branches without seeing
> any
> ordering constraint with the writes to 'b'.
>
> I.e. conditions are not 'atomic', they can be 'torn' by the compiler just as
> much
> as reads or writes can be torn.
That is an interesting test case!
PowerPC prohibits speculating the writes in your transformed case, that is,
prohibits the writes to "b" from being reordered with the read from "a".
I believe that ARM also prohibits it in that case, but must defer to
Will Deacon. Not sure about MIPS.
Or am I misunderstanding your intent with that example?
Thanx, Paul
[GIT PULL] Power management fixes for v4.7-rc4
Hi Linus, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \ pm-4.7-rc4 to receive power management fixes for v4.7-rc4 with top-most commit 9d066a252786e1a18484a6283f82614d42a9f4ac Merge branches 'pm-opp' and 'pm-cpufreq-fixes' on top of commit 5edb56491d4812c42175980759da53388e5d86f5 Linux 4.7-rc3 Fixes for two recent regressions that may lead to degraded performance (operating performance points framework, intel_pstate). Specifics: - Fix a recent regression in the intel_pstate driver that may lead to degraded performance on some systems due to missing turbo state entry in the table returned by the ACPI _PSS object (Srinivas Pandruvada). - Fix a recent regression in the OPP (operating performance points) framework that may lead to degraded performance on some systems where the OPP table is created too early (Viresh Kumar). Thanks! --- Srinivas Pandruvada (1): cpufreq: intel_pstate: Adjust _PSS[0] freqeuency if needed Viresh Kumar (1): PM / OPP: Add 'UNKNOWN' status for shared_opp in struct opp_table --- drivers/base/power/opp/cpu.c | 12 +--- drivers/base/power/opp/of.c| 10 -- drivers/base/power/opp/opp.h | 8 +++- drivers/cpufreq/intel_pstate.c | 22 ++ 4 files changed, 26 insertions(+), 26 deletions(-)
[PATCH 3/4] selftests: add media controller regression test scripts and document
Add regression test scripts open_loop_test.sh, and bind_unbind_sample.sh. Also add regression_test.txt that describes the regression test procedure. Signed-off-by: Shuah Khan --- .../selftests/media_tests/bind_unbind_sample.sh| 13 +++ .../selftests/media_tests/open_loop_test.sh| 10 + .../selftests/media_tests/regression_test.txt | 43 ++ 3 files changed, 66 insertions(+) create mode 100755 tools/testing/selftests/media_tests/bind_unbind_sample.sh create mode 100755 tools/testing/selftests/media_tests/open_loop_test.sh create mode 100644 tools/testing/selftests/media_tests/regression_test.txt diff --git a/tools/testing/selftests/media_tests/bind_unbind_sample.sh b/tools/testing/selftests/media_tests/bind_unbind_sample.sh new file mode 100755 index 000..2b24743 --- /dev/null +++ b/tools/testing/selftests/media_tests/bind_unbind_sample.sh @@ -0,0 +1,13 @@ +#!/bin/bash +# Find device number in /sys/bus/usb/drivers/drivername +# Edit this file to update the driver numer and name +# Example test for uvcvideo driver +#i=0 +# while :; do +# i=$((i+1)) +# echo 1-5:1.0 > /sys/bus/usb/drivers/uvcvideo/unbind; +# echo 1-5:1.0 > /sys/bus/usb/drivers/uvcvideo/bind; +# clear +# echo $i +#done + diff --git a/tools/testing/selftests/media_tests/open_loop_test.sh b/tools/testing/selftests/media_tests/open_loop_test.sh new file mode 100755 index 000..dcd3c17 --- /dev/null +++ b/tools/testing/selftests/media_tests/open_loop_test.sh @@ -0,0 +1,10 @@ +#!/bin/bash + i=0 +file=/dev/media$1 + while :; do + echo $file + i=$((i+1)) + R=$(./media_device_open -d $file); + # clear + echo -e "Loop $i\n$R" + done diff --git a/tools/testing/selftests/media_tests/regression_test.txt b/tools/testing/selftests/media_tests/regression_test.txt new file mode 100644 index 000..2627367 --- /dev/null +++ b/tools/testing/selftests/media_tests/regression_test.txt @@ -0,0 +1,43 @@ +Testing for regressions in Media Controller API register, ioctl, syscall, +and unregister paths. There have a few problems that result in user-after +free on media_device, media_devnode, and cdev pointers when the driver is +unbound while ioctl is in progress. + +Test Procedure: + +Run bin/unbind loop while ioctls are in progress. +Run rmmod and modprobe. +Disconnect the device. + +Setup: + +Build media_device_test +cd tools/testing/selftests/media_tests +make + +Regressions test for cdev user-after free error on /dev/mediaX when driver +is unbound: + +Start media_device_test to regression test media devnode dynamic alloc +and cdev user-after-free fixes. This opens media dev files and sits in +a loop running media ioctl MEDIA_IOC_DEVICE_INFO command once every 10 +seconds. The idea is when device file goes away, media devnode and cdev +should stick around until this test exits. + +The test for a random number of iterations or until user kills it with a +sleep 10 in between the ioctl calls. + +sudo ./media_device_test -d /dev/mediaX + +Regression test for media_devnode unregister race with ioctl_syscall: + +Start 6 open_loop_test.sh tests with different /dev/mediaX files. When +device file goes away after unbind, device file name changes. Start the +test with possible device names. If we start with /dev/media0 for example, +after unbind, /dev/media1 or /dev/media2 could get created. The idea is +keep ioctls going while bind/unbind runs. + +Copy bind_unbind_sample.txt and make changes to specify the driver name +and number to run bind and unbind. Start the bind_unbind.sh + +Run dmesg looking for any user-after free errors or mutex lock errors. -- 2.7.4
[PATCH 0/4] Add new media test and regression test scripts
This patch series changes an exixtsing test to randomize the loop count, adds a new test, and regression test scripts, and regression test how to. Shuah Khan (4): selftests: media_device_test change it to randomize loop count selftests: add media_device_open test selftests: add media controller regression test scripts and document selftests: media_tests - Add media_device_open to .gitignore tools/testing/selftests/media_tests/.gitignore | 1 + tools/testing/selftests/media_tests/Makefile | 4 +- .../selftests/media_tests/bind_unbind_sample.sh| 13 .../selftests/media_tests/media_device_open.c | 81 ++ .../selftests/media_tests/media_device_test.c | 19 +++-- .../selftests/media_tests/open_loop_test.sh| 10 +++ .../selftests/media_tests/regression_test.txt | 43 7 files changed, 163 insertions(+), 8 deletions(-) create mode 100755 tools/testing/selftests/media_tests/bind_unbind_sample.sh create mode 100644 tools/testing/selftests/media_tests/media_device_open.c create mode 100755 tools/testing/selftests/media_tests/open_loop_test.sh create mode 100644 tools/testing/selftests/media_tests/regression_test.txt -- 2.7.4
[PATCH 1/4] selftests: media_device_test change it to randomize loop count
Change it to randomize the loop count instead of hardcoded number of times
ioctl is called.
Signed-off-by: Shuah Khan
---
.../testing/selftests/media_tests/media_device_test.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/tools/testing/selftests/media_tests/media_device_test.c
b/tools/testing/selftests/media_tests/media_device_test.c
index cbf53a0..5d49943 100644
--- a/tools/testing/selftests/media_tests/media_device_test.c
+++ b/tools/testing/selftests/media_tests/media_device_test.c
@@ -1,5 +1,5 @@
/*
- * media_devkref_test.c - Media Controller Device Kref API Test
+ * media_device_test.c - Media Controller Device ioctl loop Test
*
* Copyright (c) 2016 Shuah Khan
* Copyright (c) 2016 Samsung Electronics Co., Ltd.
@@ -35,13 +35,14 @@
#include
#include
#include
+#include
#include
int main(int argc, char **argv)
{
int opt;
char media_device[256];
- int count = 0;
+ int count;
struct media_device_info mdi;
int ret;
int fd;
@@ -69,6 +70,10 @@ int main(int argc, char **argv)
exit(-1);
}
+ /* Generate random number of interations */
+ srand((unsigned int) time(NULL));
+ count = rand();
+
/* Open Media device and keep it open */
fd = open(media_device, O_RDWR);
if (fd == -1) {
@@ -82,14 +87,16 @@ int main(int argc, char **argv)
"other Oops in the dmesg. Enable KaSan kernel\n"
"config option for use-after-free error detection.\n\n");
- while (count < 100) {
+ printf("Running test for %d iternations\n", count);
+
+ while (count > 0) {
ret = ioctl(fd, MEDIA_IOC_DEVICE_INFO, &mdi);
if (ret < 0)
printf("Media Device Info errno %s\n", strerror(errno));
else
- printf("Media device model %s driver %s\n",
- mdi.model, mdi.driver);
+ printf("Media device model %s driver %s - count %d\n",
+ mdi.model, mdi.driver, count);
sleep(10);
- count++;
+ count--;
}
}
--
2.7.4
[PATCH 4/4] selftests: media_tests - Add media_device_open to .gitignore
Add media_device_open to .gitignore Signed-off-by: Shuah Khan --- tools/testing/selftests/media_tests/.gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/testing/selftests/media_tests/.gitignore b/tools/testing/selftests/media_tests/.gitignore index 1c07117..faf5891 100644 --- a/tools/testing/selftests/media_tests/.gitignore +++ b/tools/testing/selftests/media_tests/.gitignore @@ -1 +1,2 @@ media_device_test +media_device_open -- 2.7.4
[PATCH 2/4] selftests: add media_device_open test
Add a new media test to open, run ioctl, and close the media device file.
Signed-off-by: Shuah Khan
---
tools/testing/selftests/media_tests/Makefile | 4 +-
.../selftests/media_tests/media_device_open.c | 81 ++
2 files changed, 83 insertions(+), 2 deletions(-)
create mode 100644 tools/testing/selftests/media_tests/media_device_open.c
diff --git a/tools/testing/selftests/media_tests/Makefile
b/tools/testing/selftests/media_tests/Makefile
index 7071bcc..177256a 100644
--- a/tools/testing/selftests/media_tests/Makefile
+++ b/tools/testing/selftests/media_tests/Makefile
@@ -1,7 +1,7 @@
-TEST_PROGS := media_device_test
+TEST_PROGS := media_device_test media_device_open
all: $(TEST_PROGS)
include ../lib.mk
clean:
- rm -fr media_device_test
+ rm -fr media_device_test media_device_open
diff --git a/tools/testing/selftests/media_tests/media_device_open.c
b/tools/testing/selftests/media_tests/media_device_open.c
new file mode 100644
index 000..44343c0
--- /dev/null
+++ b/tools/testing/selftests/media_tests/media_device_open.c
@@ -0,0 +1,81 @@
+/*
+ * media_device_open.c - Media Controller Device Open Test
+ *
+ * Copyright (c) 2016 Shuah Khan
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ *
+ * This file is released under the GPLv2.
+ */
+
+/*
+ * This file adds a test for Media Controller API.
+ * This test should be run as root and should not be
+ * included in the Kselftest run. This test should be
+ * run when hardware and driver that makes use Media
+ * Controller API are present in the system.
+ *
+ * This test opens user specified Media Device and calls
+ * MEDIA_IOC_DEVICE_INFO ioctl, closes the file, and exits.
+ *
+ * Usage:
+ * sudo ./media_device_open -d /dev/mediaX
+ *
+ * Run this test is a loop and run bind/unbind on the driver.
+*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+int main(int argc, char **argv)
+{
+ int opt;
+ char media_device[256];
+ int count = 0;
+ struct media_device_info mdi;
+ int ret;
+ int fd;
+
+ if (argc < 2) {
+ printf("Usage: %s [-d ]\n", argv[0]);
+ exit(-1);
+ }
+
+ /* Process arguments */
+ while ((opt = getopt(argc, argv, "d:")) != -1) {
+ switch (opt) {
+ case 'd':
+ strncpy(media_device, optarg, sizeof(media_device) - 1);
+ media_device[sizeof(media_device)-1] = '\0';
+ break;
+ default:
+ printf("Usage: %s [-d ]\n", argv[0]);
+ exit(-1);
+ }
+ }
+
+ if (getuid() != 0) {
+ printf("Please run the test as root - Exiting.\n");
+ exit(-1);
+ }
+
+ /* Open Media device and keep it open */
+ fd = open(media_device, O_RDWR);
+ if (fd == -1) {
+ printf("Media Device open errno %s\n", strerror(errno));
+ exit(-1);
+ }
+
+ ret = ioctl(fd, MEDIA_IOC_DEVICE_INFO, &mdi);
+ if (ret < 0)
+ printf("Media Device Info errno %s\n", strerror(errno));
+ else
+ printf("Media device model %s driver %s\n",
+ mdi.model, mdi.driver);
+}
--
2.7.4
[PATCH] x86: fux duplicated X86_BUG(9) macro
Now sending with actual stable@ address... -- From: Dave Hansen cpufeatures.h currently defines X86_BUG(9) twice on 32-bit: #define X86_BUG_NULL_SEGX86_BUG(9) /* Nulling a selector preserves the base */ ... #ifdef CONFIG_X86_32 #define X86_BUG_ESPFIX X86_BUG(9) /* "" IRET to 16-bit SS corrupts ESP/RSP high bits */ #endif I think what happened was that this added the X86_BUG_ESPFIX, but in an #ifdef below most of the bugs: [58a5aac5] x86/entry/32: Introduce and use X86_BUG_ESPFIX instead of paravirt_enabled Then this came along and added X86_BUG_NULL_SEG, but collided with the earlier one that did the bug below the main block defining all the X86_BUG()s. [7a5d6704] x86/cpu: Probe the behavior of nulling out a segment at boot time Signed-off-by: Dave Hansen Cc: Andy Lutomirski Cc: sta...@vger.kernel.org --- b/arch/x86/include/asm/cpufeatures.h |6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff -puN arch/x86/include/asm/cpufeatures.h~fix-x86-bugs-macros arch/x86/include/asm/cpufeatures.h --- a/arch/x86/include/asm/cpufeatures.h~fix-x86-bugs-macros2016-06-17 17:10:30.978602807 -0700 +++ b/arch/x86/include/asm/cpufeatures.h2016-06-17 17:10:30.982602989 -0700 @@ -301,10 +301,6 @@ #define X86_BUG_FXSAVE_LEAKX86_BUG(6) /* FXSAVE leaks FOP/FIP/FOP */ #define X86_BUG_CLFLUSH_MONITORX86_BUG(7) /* AAI65, CLFLUSH required before MONITOR */ #define X86_BUG_SYSRET_SS_ATTRSX86_BUG(8) /* SYSRET doesn't fix up SS attrs */ -#define X86_BUG_NULL_SEG X86_BUG(9) /* Nulling a selector preserves the base */ -#define X86_BUG_SWAPGS_FENCE X86_BUG(10) /* SWAPGS without input dep on GS */ - - #ifdef CONFIG_X86_32 /* * 64-bit kernels don't use X86_BUG_ESPFIX. Make the define conditional @@ -312,5 +308,7 @@ */ #define X86_BUG_ESPFIX X86_BUG(9) /* "" IRET to 16-bit SS corrupts ESP/RSP high bits */ #endif +#define X86_BUG_NULL_SEG X86_BUG(10) /* Nulling a selector preserves the base */ +#define X86_BUG_SWAPGS_FENCE X86_BUG(11) /* SWAPGS without input dep on GS */ #endif /* _ASM_X86_CPUFEATURES_H */ _
[PATCH v3 net-next v3 02/14] net: dsa: mv88e6xxx: remove redundant assignments
The chip->ds and ds->slave_mii_bus assignments are common to both legacy and new MDIO probing and are already done in the later setup code. Remove the duplicated assignments from the MDIO probing code. Signed-off-by: Vivien Didelot Reviewed-by: Andrew Lunn --- drivers/net/dsa/mv88e6xxx.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c index 1972ec5..673283a 100644 --- a/drivers/net/dsa/mv88e6xxx.c +++ b/drivers/net/dsa/mv88e6xxx.c @@ -3708,7 +3708,6 @@ static int mv88e6xxx_probe(struct mdio_device *mdiodev) ds->priv = ps; ds->dev = dev; ps->dev = dev; - ps->ds = ds; ps->bus = mdiodev->bus; ps->sw_addr = mdiodev->addr; mutex_init(&ps->smi_mutex); @@ -3748,8 +3747,6 @@ static int mv88e6xxx_probe(struct mdio_device *mdiodev) if (err) return err; - ds->slave_mii_bus = ps->mdio_bus; - dev_set_drvdata(dev, ds); err = dsa_register_switch(ds, mdiodev->dev.of_node); -- 2.8.3
[PATCH v3 net-next v3 08/14] net: dsa: mv88e6xxx: rename smi_mutex to reg_lock
The chip smi_mutex mutex is used to protect the access to the internal
switch registers, not only the Multi-chip Addressing Mode, as commented.
Other registers access (like management frames) may use this mutex.
Since we will isolate SMI-specific pieces of code, avoid the confusion
now by renaming smi_mutex to reg_lock. No functional changes here.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx.c | 120 ++--
drivers/net/dsa/mv88e6xxx.h | 7 +--
2 files changed, 62 insertions(+), 65 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 75e5408..2c86172 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -29,10 +29,10 @@
#include
#include "mv88e6xxx.h"
-static void assert_smi_lock(struct mv88e6xxx_priv_state *ps)
+static void assert_reg_lock(struct mv88e6xxx_priv_state *ps)
{
- if (unlikely(!mutex_is_locked(&ps->smi_mutex))) {
- dev_err(ps->dev, "SMI lock not held!\n");
+ if (unlikely(!mutex_is_locked(&ps->reg_lock))) {
+ dev_err(ps->dev, "Switch registers lock not held!\n");
dump_stack();
}
}
@@ -99,7 +99,7 @@ static int _mv88e6xxx_reg_read(struct mv88e6xxx_priv_state
*ps,
{
int ret;
- assert_smi_lock(ps);
+ assert_reg_lock(ps);
ret = __mv88e6xxx_reg_read(ps->bus, ps->sw_addr, addr, reg);
if (ret < 0)
@@ -116,9 +116,9 @@ static int mv88e6xxx_reg_read(struct mv88e6xxx_priv_state
*ps, int addr,
{
int ret;
- mutex_lock(&ps->smi_mutex);
+ mutex_lock(&ps->reg_lock);
ret = _mv88e6xxx_reg_read(ps, addr, reg);
- mutex_unlock(&ps->smi_mutex);
+ mutex_unlock(&ps->reg_lock);
return ret;
}
@@ -158,7 +158,7 @@ static int __mv88e6xxx_reg_write(struct mii_bus *bus, int
sw_addr, int addr,
static int _mv88e6xxx_reg_write(struct mv88e6xxx_priv_state *ps, int addr,
int reg, u16 val)
{
- assert_smi_lock(ps);
+ assert_reg_lock(ps);
dev_dbg(ps->dev, "-> addr: 0x%.2x reg: 0x%.2x val: 0x%.4x\n",
addr, reg, val);
@@ -171,9 +171,9 @@ static int mv88e6xxx_reg_write(struct mv88e6xxx_priv_state
*ps, int addr,
{
int ret;
- mutex_lock(&ps->smi_mutex);
+ mutex_lock(&ps->reg_lock);
ret = _mv88e6xxx_reg_write(ps, addr, reg, val);
- mutex_unlock(&ps->smi_mutex);
+ mutex_unlock(&ps->reg_lock);
return ret;
}
@@ -320,7 +320,7 @@ static void mv88e6xxx_ppu_reenable_work(struct work_struct
*ugly)
ps = container_of(ugly, struct mv88e6xxx_priv_state, ppu_work);
- mutex_lock(&ps->smi_mutex);
+ mutex_lock(&ps->reg_lock);
if (mutex_trylock(&ps->ppu_mutex)) {
if (mv88e6xxx_ppu_enable(ps) == 0)
@@ -328,7 +328,7 @@ static void mv88e6xxx_ppu_reenable_work(struct work_struct
*ugly)
mutex_unlock(&ps->ppu_mutex);
}
- mutex_unlock(&ps->smi_mutex);
+ mutex_unlock(&ps->reg_lock);
}
static void mv88e6xxx_ppu_reenable_timer(unsigned long _ps)
@@ -477,7 +477,7 @@ static void mv88e6xxx_adjust_link(struct dsa_switch *ds,
int port,
if (!phy_is_pseudo_fixed_link(phydev))
return;
- mutex_lock(&ps->smi_mutex);
+ mutex_lock(&ps->reg_lock);
ret = _mv88e6xxx_reg_read(ps, REG_PORT(port), PORT_PCS_CTRL);
if (ret < 0)
@@ -528,7 +528,7 @@ static void mv88e6xxx_adjust_link(struct dsa_switch *ds,
int port,
_mv88e6xxx_reg_write(ps, REG_PORT(port), PORT_PCS_CTRL, reg);
out:
- mutex_unlock(&ps->smi_mutex);
+ mutex_unlock(&ps->reg_lock);
}
static int _mv88e6xxx_stats_wait(struct mv88e6xxx_priv_state *ps)
@@ -753,11 +753,11 @@ static void mv88e6xxx_get_ethtool_stats(struct dsa_switch
*ds, int port,
int ret;
int i, j;
- mutex_lock(&ps->smi_mutex);
+ mutex_lock(&ps->reg_lock);
ret = _mv88e6xxx_stats_snapshot(ps, port);
if (ret < 0) {
- mutex_unlock(&ps->smi_mutex);
+ mutex_unlock(&ps->reg_lock);
return;
}
for (i = 0, j = 0; i < ARRAY_SIZE(mv88e6xxx_hw_stats); i++) {
@@ -768,7 +768,7 @@ static void mv88e6xxx_get_ethtool_stats(struct dsa_switch
*ds, int port,
}
}
- mutex_unlock(&ps->smi_mutex);
+ mutex_unlock(&ps->reg_lock);
}
static int mv88e6xxx_get_regs_len(struct dsa_switch *ds, int port)
@@ -787,7 +787,7 @@ static void mv88e6xxx_get_regs(struct dsa_switch *ds, int
port,
memset(p, 0xff, 32 * sizeof(u16));
- mutex_lock(&ps->smi_mutex);
+ mutex_lock(&ps->reg_lock);
for (i = 0; i < 32; i++) {
int ret;
@@ -797,7 +797,7 @@ static void mv88e6xxx_get_regs(struct dsa_switch *ds, int
port,
p[i] = ret;
}
- mutex_unlock(&ps->smi_mutex);
+ mutex_unlock(&ps->reg_lock
[PATCH v3 net-next v3 01/14] net: dsa: mv88e6xxx: fix style issues
This patch fixes 5 style problems reported by checkpatch:
WARNING: suspect code indent for conditional statements (8, 24)
#492: FILE: drivers/net/dsa/mv88e6xxx.c:492:
+ if (phydev->link)
+ reg |= PORT_PCS_CTRL_LINK_UP;
CHECK: Logical continuations should be on the previous line
#1318: FILE: drivers/net/dsa/mv88e6xxx.c:1318:
+oldstate == PORT_CONTROL_STATE_FORWARDING)
+ && (state == PORT_CONTROL_STATE_DISABLED ||
CHECK: multiple assignments should be avoided
#1662: FILE: drivers/net/dsa/mv88e6xxx.c:1662:
+ vlan->vid_begin = vlan->vid_end = next.vid;
WARNING: line over 80 characters
#2097: FILE: drivers/net/dsa/mv88e6xxx.c:2097:
+ const struct switchdev_obj_port_vlan
*vlan,
WARNING: suspect code indent for conditional statements (16, 32)
#2734: FILE: drivers/net/dsa/mv88e6xxx.c:2734:
+ if (mv88e6xxx_6352_family(ps) || mv88e6xxx_6351_family(ps) ||
[...]
+ reg |= PORT_CONTROL_EGRESS_ADD_TAG;
total: 0 errors, 3 warnings, 2 checks, 3805 lines checked
It also rebases and integrates changes sent by Ben Dooks [1]:
The driver has a number of functions that are not exported or
declared elsewhere, so make them static to avoid the following
warnings from sparse:
drivers/net/dsa/mv88e6xxx.c:113:5: warning: symbol 'mv88e6xxx_reg_read' was
not declared. Should it be static?
drivers/net/dsa/mv88e6xxx.c:167:5: warning: symbol 'mv88e6xxx_reg_write'
was not declared. Should it be static?
drivers/net/dsa/mv88e6xxx.c:231:5: warning: symbol 'mv88e6xxx_set_addr' was
not declared. Should it be static?
drivers/net/dsa/mv88e6xxx.c:367:6: warning: symbol
'mv88e6xxx_ppu_state_init' was not declared. Should it be static?
drivers/net/dsa/mv88e6xxx.c:3157:5: warning: symbol
'mv88e6xxx_phy_page_read' was not declared. Should it be static?
drivers/net/dsa/mv88e6xxx.c:3169:5: warning: symbol
'mv88e6xxx_phy_page_write' was not declared. Should it be static?
drivers/net/dsa/mv88e6xxx.c:3583:26: warning: symbol
'mv88e6xxx_switch_driver' was not declared. Should it be static?
drivers/net/dsa/mv88e6xxx.c:3621:5: warning: symbol 'mv88e6xxx_probe' was
not declared. Should it be static?
[1] http://patchwork.ozlabs.org/patch/632708/
Signed-off-by: Vivien Didelot
Reviewed-by: Andrew Lunn
---
drivers/net/dsa/mv88e6xxx.c | 42 +++---
1 file changed, 23 insertions(+), 19 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index ee06055..1972ec5 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -111,7 +111,8 @@ static int _mv88e6xxx_reg_read(struct mv88e6xxx_priv_state
*ps,
return ret;
}
-int mv88e6xxx_reg_read(struct mv88e6xxx_priv_state *ps, int addr, int reg)
+static int mv88e6xxx_reg_read(struct mv88e6xxx_priv_state *ps, int addr,
+ int reg)
{
int ret;
@@ -165,8 +166,8 @@ static int _mv88e6xxx_reg_write(struct mv88e6xxx_priv_state
*ps, int addr,
return __mv88e6xxx_reg_write(ps->bus, ps->sw_addr, addr, reg, val);
}
-int mv88e6xxx_reg_write(struct mv88e6xxx_priv_state *ps, int addr,
- int reg, u16 val)
+static int mv88e6xxx_reg_write(struct mv88e6xxx_priv_state *ps, int addr,
+ int reg, u16 val)
{
int ret;
@@ -229,7 +230,7 @@ static int mv88e6xxx_set_addr_indirect(struct dsa_switch
*ds, u8 *addr)
return 0;
}
-int mv88e6xxx_set_addr(struct dsa_switch *ds, u8 *addr)
+static int mv88e6xxx_set_addr(struct dsa_switch *ds, u8 *addr)
{
struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
@@ -370,7 +371,7 @@ static void mv88e6xxx_ppu_access_put(struct
mv88e6xxx_priv_state *ps)
mutex_unlock(&ps->ppu_mutex);
}
-void mv88e6xxx_ppu_state_init(struct mv88e6xxx_priv_state *ps)
+static void mv88e6xxx_ppu_state_init(struct mv88e6xxx_priv_state *ps)
{
mutex_init(&ps->ppu_mutex);
INIT_WORK(&ps->ppu_work, mv88e6xxx_ppu_reenable_work);
@@ -490,7 +491,7 @@ static void mv88e6xxx_adjust_link(struct dsa_switch *ds,
int port,
reg |= PORT_PCS_CTRL_FORCE_LINK;
if (phydev->link)
- reg |= PORT_PCS_CTRL_LINK_UP;
+ reg |= PORT_PCS_CTRL_LINK_UP;
if (mv88e6xxx_6065_family(ps) && phydev->speed > SPEED_100)
goto out;
@@ -1314,9 +1315,9 @@ static int _mv88e6xxx_port_state(struct
mv88e6xxx_priv_state *ps, int port,
* Blocking or Listening state.
*/
if ((oldstate == PORT_CONTROL_STATE_LEARNING ||
-oldstate == PORT_CONTROL_STATE_FORWARDING)
- && (state == PORT_CONTROL_STATE_DISABLED ||
- state == PORT_CONTROL_STATE_BLOCKING)) {
+oldstate == PORT_
[PATCH v3 net-next v3 14/14] net: dsa: mv88e6xxx: add port base address to info
The switch ID is located at address 0x3 of every Port Registers bank.
But not all Marvell switches have their Port Registers SMI Addresses
starting at 0x10. 88E6060 starts at 0x8 and 88E6390 starts at 0x0.
Add this data in the info structure and use it in the detection code.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx.c | 19 ++-
drivers/net/dsa/mv88e6xxx.h | 1 +
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 4d32f5a..aeb96db 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -3511,6 +3511,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6085",
.num_databases = 4096,
.num_ports = 10,
+ .port_base_addr = 0x10,
.flags = MV88E6XXX_FLAGS_FAMILY_6097,
},
@@ -3520,6 +3521,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6095/88E6095F",
.num_databases = 256,
.num_ports = 11,
+ .port_base_addr = 0x10,
.flags = MV88E6XXX_FLAGS_FAMILY_6095,
},
@@ -3529,6 +3531,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6123",
.num_databases = 4096,
.num_ports = 3,
+ .port_base_addr = 0x10,
.flags = MV88E6XXX_FLAGS_FAMILY_6165,
},
@@ -3538,6 +3541,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6131",
.num_databases = 256,
.num_ports = 8,
+ .port_base_addr = 0x10,
.flags = MV88E6XXX_FLAGS_FAMILY_6185,
},
@@ -3547,6 +3551,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6161",
.num_databases = 4096,
.num_ports = 6,
+ .port_base_addr = 0x10,
.flags = MV88E6XXX_FLAGS_FAMILY_6165,
},
@@ -3556,6 +3561,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6165",
.num_databases = 4096,
.num_ports = 6,
+ .port_base_addr = 0x10,
.flags = MV88E6XXX_FLAGS_FAMILY_6165,
},
@@ -3565,6 +3571,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6171",
.num_databases = 4096,
.num_ports = 7,
+ .port_base_addr = 0x10,
.flags = MV88E6XXX_FLAGS_FAMILY_6351,
},
@@ -3574,6 +3581,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6172",
.num_databases = 4096,
.num_ports = 7,
+ .port_base_addr = 0x10,
.flags = MV88E6XXX_FLAGS_FAMILY_6352,
},
@@ -3583,6 +3591,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6175",
.num_databases = 4096,
.num_ports = 7,
+ .port_base_addr = 0x10,
.flags = MV88E6XXX_FLAGS_FAMILY_6351,
},
@@ -3592,6 +3601,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6176",
.num_databases = 4096,
.num_ports = 7,
+ .port_base_addr = 0x10,
.flags = MV88E6XXX_FLAGS_FAMILY_6352,
},
@@ -3601,6 +3611,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6185",
.num_databases = 256,
.num_ports = 10,
+ .port_base_addr = 0x10,
.flags = MV88E6XXX_FLAGS_FAMILY_6185,
},
@@ -3610,6 +3621,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6240",
.num_databases = 4096,
.num_ports = 7,
+ .port_base_addr = 0x10,
.flags = MV88E6XXX_FLAGS_FAMILY_6352,
},
@@ -3619,6 +3631,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6320",
.num_databases = 4096,
.num_ports = 7,
+ .port_base_addr = 0x10,
.flags = MV88E6XXX_FLAGS_FAMILY_6320,
},
@@ -3628,6 +3641,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6321",
.num_databases = 4096,
.num_ports = 7,
+ .port_base_addr = 0x10,
.flags = MV88E6XXX_FLAGS_FAMILY_6320,
},
@@ -3637,6 +3651,7 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
.name = "Marvell 88E6350",
.num_databases = 4096,
[PATCH v3 net-next v3 07/14] net: dsa: mv88e6xxx: remove table args in info lookup
The mv88e6xxx_table array and the mv88e6xxx_lookup_info function are
static, so remove the table and size arguments from the lookup function.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index ec28465..75e5408 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -3590,15 +3590,13 @@ static const struct mv88e6xxx_info mv88e6xxx_table[] = {
},
};
-static const struct mv88e6xxx_info *
-mv88e6xxx_lookup_info(unsigned int prod_num, const struct mv88e6xxx_info
*table,
- unsigned int num)
+static const struct mv88e6xxx_info *mv88e6xxx_lookup_info(unsigned int
prod_num)
{
int i;
- for (i = 0; i < num; ++i)
- if (table[i].prod_num == prod_num)
- return &table[i];
+ for (i = 0; i < ARRAY_SIZE(mv88e6xxx_table); ++i)
+ if (mv88e6xxx_table[i].prod_num == prod_num)
+ return &mv88e6xxx_table[i];
return NULL;
}
@@ -3625,8 +3623,7 @@ static const char *mv88e6xxx_drv_probe(struct device
*dsa_dev,
prod_num = (id & 0xfff0) >> 4;
rev = id & 0x000f;
- info = mv88e6xxx_lookup_info(prod_num, mv88e6xxx_table,
-ARRAY_SIZE(mv88e6xxx_table));
+ info = mv88e6xxx_lookup_info(prod_num);
if (!info)
return NULL;
@@ -3739,8 +3736,7 @@ static int mv88e6xxx_probe(struct mdio_device *mdiodev)
prod_num = (id & 0xfff0) >> 4;
rev = id & 0x000f;
- ps->info = mv88e6xxx_lookup_info(prod_num, mv88e6xxx_table,
-ARRAY_SIZE(mv88e6xxx_table));
+ ps->info = mv88e6xxx_lookup_info(prod_num);
if (!ps->info)
return -ENODEV;
--
2.8.3
[PATCH v3 net-next v3 10/14] net: dsa: mv88e6xxx: add SMI init helper
Add an helper function to isolate SMI specific assignations and checks.
This function will later help choosing the different SMI accesses based
of the compatible info.
Since the chip structure is already allocated in the legacy probe, use
the mv88e6xxx_reg_read access routine instead of __mv88e6xxx_reg_read.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx.c | 26 +-
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 113092a..4e24ac5 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -3616,6 +3616,19 @@ static struct mv88e6xxx_priv_state
*mv88e6xxx_alloc_chip(struct device *dev)
return ps;
}
+static int mv88e6xxx_smi_init(struct mv88e6xxx_priv_state *ps,
+ struct mii_bus *bus, int sw_addr)
+{
+ /* ADDR[0] pin is unavailable externally and considered zero */
+ if (sw_addr & 0x1)
+ return -EINVAL;
+
+ ps->bus = bus;
+ ps->sw_addr = sw_addr;
+
+ return 0;
+}
+
static const char *mv88e6xxx_drv_probe(struct device *dsa_dev,
struct device *host_dev, int sw_addr,
void **priv)
@@ -3635,7 +3648,11 @@ static const char *mv88e6xxx_drv_probe(struct device
*dsa_dev,
if (!ps)
return NULL;
- id = __mv88e6xxx_reg_read(bus, sw_addr, REG_PORT(0), PORT_SWITCH_ID);
+ err = mv88e6xxx_smi_init(ps, bus, sw_addr);
+ if (err)
+ goto free;
+
+ id = mv88e6xxx_reg_read(ps, REG_PORT(0), PORT_SWITCH_ID);
if (id < 0)
goto free;
@@ -3648,8 +3665,6 @@ static const char *mv88e6xxx_drv_probe(struct device
*dsa_dev,
name = info->name;
- ps->bus = bus;
- ps->sw_addr = sw_addr;
ps->info = info;
err = mv88e6xxx_mdio_register(ps, NULL);
@@ -3741,8 +3756,9 @@ static int mv88e6xxx_probe(struct mdio_device *mdiodev)
if (!ps)
return -ENOMEM;
- ps->bus = mdiodev->bus;
- ps->sw_addr = mdiodev->addr;
+ err = mv88e6xxx_smi_init(ps, mdiodev->bus, mdiodev->addr);
+ if (err)
+ return err;
id = mv88e6xxx_reg_read(ps, REG_PORT(0), PORT_SWITCH_ID);
if (id < 0)
--
2.8.3
[PATCH v3 net-next v3 06/14] net: dsa: mv88e6xxx: use gpio get optional variant
Use the optional variant to get the reset GPIO line, instead of checking
for the -ENOENT error.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index ad7735d..ec28465 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -3744,16 +3744,9 @@ static int mv88e6xxx_probe(struct mdio_device *mdiodev)
if (!ps->info)
return -ENODEV;
- ps->reset = devm_gpiod_get(dev, "reset", GPIOD_ASIS);
- if (IS_ERR(ps->reset)) {
- err = PTR_ERR(ps->reset);
- if (err == -ENOENT) {
- /* Optional, so not an error */
- ps->reset = NULL;
- } else {
- return err;
- }
- }
+ ps->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_ASIS);
+ if (IS_ERR(ps->reset))
+ return PTR_ERR(ps->reset);
if (mv88e6xxx_has(ps, MV88E6XXX_FLAG_EEPROM) &&
!of_property_read_u32(np, "eeprom-length", &eeprom_len))
--
2.8.3
[PATCH v3 net-next v3 00/14] net: dsa: mv88e6xxx: probe compatible
This patchset factorizes the legacy DSA probing and the new MDIO probing functions with a few helpers. This will allow us to use a compatible chip info to describe how to access the SMI device and its switch ID register at probe time. For the legacy probe, we fix the compatible info to 88E6085. For the MDIO probe, we will use the compatible info from the device node data. The first 5 patches are already reviewed. The next 3 patches are cosmetics, with no functional changes. The next 4 patches add probe helpers and pass the compatible info. The last 2 patches extend the info structure to store the SMI access mode and the location of the switch ID register. Changes since v2 [2]: - do not guess compatible model in legacy probe - add low level SMI API using a chip structure - allocate before probe and detection - add 3 cosmetic patches Changes since v1 [1]: - merge style fix from Ben Dooks - add Acked-by/Reviewed-by tags - drop one compatible string per model - detect the SMI device based on the compatible info - add an SMI ops structure [1] https://lkml.org/lkml/2016/6/8/1201 [2] https://lkml.org/lkml/2016/6/14/671 Vivien Didelot (14): net: dsa: mv88e6xxx: fix style issues net: dsa: mv88e6xxx: remove redundant assignments net: dsa: mv88e6xxx: use already declared variables net: dsa: mv88e6xxx: do not increment bus refcount net: dsa: mv88e6xxx: add switch register helpers net: dsa: mv88e6xxx: use gpio get optional variant net: dsa: mv88e6xxx: remove table args in info lookup net: dsa: mv88e6xxx: rename smi_mutex to reg_lock net: dsa: mv88e6xxx: add chip allocation helper net: dsa: mv88e6xxx: add SMI init helper net: dsa: mv88e6xxx: add detection helper net: dsa: mv88e6xxx: pass compatible info net: dsa: mv88e6xxx: add addressing mode to info net: dsa: mv88e6xxx: add port base address to info drivers/net/dsa/mv88e6xxx.c | 508 drivers/net/dsa/mv88e6xxx.h | 27 ++- 2 files changed, 343 insertions(+), 192 deletions(-) -- 2.8.3
[PATCH] x86: fux duplicated X86_BUG(9) macro
From: Dave Hansen cpufeatures.h currently defines X86_BUG(9) twice on 32-bit: #define X86_BUG_NULL_SEGX86_BUG(9) /* Nulling a selector preserves the base */ ... #ifdef CONFIG_X86_32 #define X86_BUG_ESPFIX X86_BUG(9) /* "" IRET to 16-bit SS corrupts ESP/RSP high bits */ #endif I think what happened was that this added the X86_BUG_ESPFIX, but in an #ifdef below most of the bugs: [58a5aac5] x86/entry/32: Introduce and use X86_BUG_ESPFIX instead of paravirt_enabled Then this came along and added X86_BUG_NULL_SEG, but collided with the earlier one that did the bug below the main block defining all the X86_BUG()s. [7a5d6704] x86/cpu: Probe the behavior of nulling out a segment at boot time Signed-off-by: Dave Hansen Cc: Andy Lutomirski Cc: sta...@kernel.org --- b/arch/x86/include/asm/cpufeatures.h |6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff -puN arch/x86/include/asm/cpufeatures.h~fix-x86-bugs-macros arch/x86/include/asm/cpufeatures.h --- a/arch/x86/include/asm/cpufeatures.h~fix-x86-bugs-macros2016-06-17 17:10:30.978602807 -0700 +++ b/arch/x86/include/asm/cpufeatures.h2016-06-17 17:10:30.982602989 -0700 @@ -301,10 +301,6 @@ #define X86_BUG_FXSAVE_LEAKX86_BUG(6) /* FXSAVE leaks FOP/FIP/FOP */ #define X86_BUG_CLFLUSH_MONITORX86_BUG(7) /* AAI65, CLFLUSH required before MONITOR */ #define X86_BUG_SYSRET_SS_ATTRSX86_BUG(8) /* SYSRET doesn't fix up SS attrs */ -#define X86_BUG_NULL_SEG X86_BUG(9) /* Nulling a selector preserves the base */ -#define X86_BUG_SWAPGS_FENCE X86_BUG(10) /* SWAPGS without input dep on GS */ - - #ifdef CONFIG_X86_32 /* * 64-bit kernels don't use X86_BUG_ESPFIX. Make the define conditional @@ -312,5 +308,7 @@ */ #define X86_BUG_ESPFIX X86_BUG(9) /* "" IRET to 16-bit SS corrupts ESP/RSP high bits */ #endif +#define X86_BUG_NULL_SEG X86_BUG(10) /* Nulling a selector preserves the base */ +#define X86_BUG_SWAPGS_FENCE X86_BUG(11) /* SWAPGS without input dep on GS */ #endif /* _ASM_X86_CPUFEATURES_H */ _
[PATCH v3 net-next v3 04/14] net: dsa: mv88e6xxx: do not increment bus refcount
The MDIO device probe and remove functions are respectively incrementing and decrementing the bus refcount themselves. Since these bus level actions are out of the device scope, remove them. Signed-off-by: Vivien Didelot Acked-by: Andrew Lunn --- drivers/net/dsa/mv88e6xxx.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c index b3170ea..4b4bffc 100644 --- a/drivers/net/dsa/mv88e6xxx.c +++ b/drivers/net/dsa/mv88e6xxx.c @@ -3712,8 +3712,6 @@ static int mv88e6xxx_probe(struct mdio_device *mdiodev) ps->sw_addr = mdiodev->addr; mutex_init(&ps->smi_mutex); - get_device(&ps->bus->dev); - ds->drv = &mv88e6xxx_switch_driver; id = mv88e6xxx_reg_read(ps, REG_PORT(0), PORT_SWITCH_ID); @@ -3767,7 +3765,6 @@ static void mv88e6xxx_remove(struct mdio_device *mdiodev) struct mv88e6xxx_priv_state *ps = ds_to_priv(ds); dsa_unregister_switch(ds); - put_device(&ps->bus->dev); mv88e6xxx_mdio_unregister(ps); } -- 2.8.3
Re: [RFC PATCH] vhost, mm: make sure that oom_reaper doesn't reap memory read by vhost
On Fri, Jun 17, 2016 at 11:00:17AM +0200, Michal Hocko wrote:
> From: Michal Hocko
>
> vhost driver relies on copy_from_user/get_user from a kernel thread.
> This makes it impossible to reap the memory of an oom victim which
> shares mm with the vhost kernel thread because it could see a zero
> page unexpectedly and theoretically make an incorrect decision visible
> outside of the killed task context.
>
> Make sure that each place which can read from userspace is annotated
> properly and it uses copy_from_user_mm, __get_user_mm resp.
> copy_from_iter_mm. Each will get the target mm as an argument and it
> performs a pessimistic check to rule out that the oom_reaper could
> possibly unmap the particular page. __oom_reap_task then just needs to
> mark the mm as unstable before it unmaps any page.
>
> This is a preparatory patch without any functional changes because
> the oom reaper doesn't touch mm shared with kthreads yet.
>
> Signed-off-by: Michal Hocko
Will review. Answer to question below:
> ---
> Hi Michael,
> we have discussed [1] that vhost_worker pins the mm of a potential
> oom victim for too long which result into an OOM storm when other
> processes have to be killed. One way to address this issue would
> be to pin mm_count rather than mm_users and revalidate it before
> actually doing the copy (mmget_not_zero). You had concerns about
> more atomic operations in the data path. Another way would be to
> postpone exit_mm_victim to after exit_task_work but as it turned
> out other task might have the device open and pin the mm indirectly
> [2].
>
> Now I would like to attack the issue from another side which would
> be more generic. I would like to make mm's which are shared with
> kthreads oom reapable in general. This is currently not allowed
> because we do not want to risk that a kthread would see an already
> unmapped page - aka see a newly allocated zero page. At the same
> time this is really desirable because it helps to guarantee a forward
> progress on the OOM.
>
> It seems that vhost usage would suffer from this problem because
> it reads from the userspace to get (status) flags and makes some
> decisions based on the read value. I do not understand the code so I
> couldn't evaluate whether that would lead to some real problems so I
> conservatively assumed it wouldn't handle that gracefully.
Getting an error from __get_user and friends is handled gracefully.
Getting zero instead of a real value will cause userspace
memory corruption.
> If this is
> incorrect and all the paths can just cope with seeing zeros unexpectedly
> then great and I will drop the patch and move over to the oom specific
> further steps.
>
> Therefore I am proposing a kthread safe API which allows to read from
> userspace and also makes sure to do a proper exclusion with the oom
> reaper. A race would be reported by EFAULT which is already handled.
> Performance wise it would add two tests to the copy from user
> paths. Does the following change makes sense to you and would be
> acceptable? If yes I will follow up with another patch which will allow
> oom reaper for mm shared with kthread.
>
> Thanks!
>
> [1]
> http://lkml.kernel.org/r/1456765329-14890-1-git-send-email-vdavy...@virtuozzo.com
> [2] http://lkml.kernel.org/r/20160301181136-mutt-send-email-...@redhat.com
>
> drivers/vhost/scsi.c| 2 +-
> drivers/vhost/vhost.c | 18 +-
> include/linux/sched.h | 1 +
> include/linux/uaccess.h | 22 ++
> include/linux/uio.h | 10 ++
> mm/oom_kill.c | 6 ++
> 6 files changed, 49 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
> index 0e6fd556c982..2c8dc0b9a21f 100644
> --- a/drivers/vhost/scsi.c
> +++ b/drivers/vhost/scsi.c
> @@ -932,7 +932,7 @@ vhost_scsi_handle_vq(struct vhost_scsi *vs, struct
> vhost_virtqueue *vq)
>*/
> iov_iter_init(&out_iter, WRITE, vq->iov, out, out_size);
>
> - ret = copy_from_iter(req, req_size, &out_iter);
> + ret = copy_from_iter_mm(vq->dev->mm, req, req_size, &out_iter);
> if (unlikely(ret != req_size)) {
> vq_err(vq, "Faulted on copy_from_iter\n");
> vhost_scsi_send_bad_target(vs, vq, head, out);
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index 669fef1e2bb6..14959ba43cb4 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -1212,7 +1212,7 @@ int vhost_vq_init_access(struct vhost_virtqueue *vq)
> r = -EFAULT;
> goto err;
> }
> - r = __get_user(last_used_idx, &vq->used->idx);
> + r = __get_user_mm(vq->dev->mm, last_used_idx, &vq->used->idx);
> if (r)
> goto err;
> vq->last_used_idx = vhost16_to_cpu(vq, last_used_idx);
> @@ -1328,7 +1328,7 @@ static int get_indirect(struct vhost_virtqueue *vq,
> i, count);
>
[PATCH v3 net-next v3 13/14] net: dsa: mv88e6xxx: add addressing mode to info
When the SMI address of the switch chip is zero, the chip assumes to be
the only one on the SMI master bus and thus responds to all its known
SMI devices addresses (port registers, Global2, etc.)
When its SMI address is not zero, some chips (e.g. 88E6352) use an
indirect access through two SMI Command and Data registers.
Other models (e.g. 88E6060) using less than 16 internal SMI addresses
always use a direct access.
Add a capability flag to describe chips supporting the (indirect)
Multi-chip Addressing Mode, and a low-level API to access the registers
via SMI.
Other accesses (like Ethernet management frames) may be added later.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx.c | 135 ++--
drivers/net/dsa/mv88e6xxx.h | 19 ++-
2 files changed, 123 insertions(+), 31 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index cadd1e3..4d32f5a 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -38,15 +38,75 @@ static void assert_reg_lock(struct mv88e6xxx_priv_state *ps)
}
}
-/* If the switch's ADDR[4:0] strap pins are strapped to zero, it will
- * use all 32 SMI bus addresses on its SMI bus, and all switch registers
- * will be directly accessible on some {device address,register address}
- * pair. If the ADDR[4:0] pins are not strapped to zero, the switch
- * will only respond to SMI transactions to that specific address, and
- * an indirect addressing mechanism needs to be used to access its
- * registers.
+/* The switch ADDR[4:1] configuration pins define the chip SMI device address
+ * (ADDR[0] is always zero, thus only even SMI addresses can be strapped).
+ *
+ * When ADDR is all zero, the chip uses Single-chip Addressing Mode, assuming
it
+ * is the only device connected to the SMI master. In this mode it responds to
+ * all 32 possible SMI addresses, and thus maps directly the internal devices.
+ *
+ * When ADDR is non-zero, the chip uses Multi-chip Addressing Mode, allowing
+ * multiple devices to share the SMI interface. In this mode it responds to
only
+ * 2 registers, used to indirectly access the internal SMI devices.
*/
-static int mv88e6xxx_reg_wait_ready(struct mii_bus *bus, int sw_addr)
+
+struct mv88e6xxx_smi_ops {
+ int (*read)(struct mii_bus *bus, int sw_addr,
+ int addr, int reg, u16 *val);
+ int (*write)(struct mii_bus *bus, int sw_addr,
+int addr, int reg, u16 val);
+};
+
+static int mv88e6xxx_smi_read(struct mv88e6xxx_priv_state *ps,
+ int addr, int reg, u16 *val)
+{
+ if (!ps->smi_ops)
+ return -EOPNOTSUPP;
+
+ return ps->smi_ops->read(ps->bus, ps->sw_addr, addr, reg, val);
+}
+
+static int mv88e6xxx_smi_write(struct mv88e6xxx_priv_state *ps,
+ int addr, int reg, u16 val)
+{
+ if (!ps->smi_ops)
+ return -EOPNOTSUPP;
+
+ return ps->smi_ops->write(ps->bus, ps->sw_addr, addr, reg, val);
+}
+
+static int mv88e6xxx_smi_single_chip_read(struct mii_bus *bus, int sw_addr,
+ int addr, int reg, u16 *val)
+{
+ int ret;
+
+ ret = mdiobus_read_nested(bus, addr, reg);
+ if (ret < 0)
+ return ret;
+
+ *val = ret & 0x;
+
+ return 0;
+}
+
+static int mv88e6xxx_smi_single_chip_write(struct mii_bus *bus, int sw_addr,
+ int addr, int reg, u16 val)
+{
+ int ret;
+
+ ret = mdiobus_write_nested(bus, addr, reg, val);
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+static const struct mv88e6xxx_smi_ops mv88e6xxx_smi_single_chip_ops = {
+ .read = mv88e6xxx_smi_single_chip_read,
+ .write = mv88e6xxx_smi_single_chip_write,
+};
+
+static int mv88e6xxx_smi_multi_chip_wait(struct mii_bus *bus, int sw_addr)
{
int ret;
int i;
@@ -63,16 +123,13 @@ static int mv88e6xxx_reg_wait_ready(struct mii_bus *bus,
int sw_addr)
return -ETIMEDOUT;
}
-static int __mv88e6xxx_reg_read(struct mii_bus *bus, int sw_addr, int addr,
- int reg)
+static int mv88e6xxx_smi_multi_chip_read(struct mii_bus *bus, int sw_addr,
+int addr, int reg, u16 *val)
{
int ret;
- if (sw_addr == 0)
- return mdiobus_read_nested(bus, addr, reg);
-
/* Wait for the bus to become free. */
- ret = mv88e6xxx_reg_wait_ready(bus, sw_addr);
+ ret = mv88e6xxx_smi_multi_chip_wait(bus, sw_addr);
if (ret < 0)
return ret;
@@ -83,7 +140,7 @@ static int __mv88e6xxx_reg_read(struct mii_bus *bus, int
sw_addr, int addr,
return ret;
/* Wait for the read command to complete. */
- ret = mv88e6xxx_reg_wait_ready(bus, sw_addr);
+ ret = mv88e6xxx_smi_multi_chip_wait(bus, sw_addr);
if (ret < 0)
[PATCH v3 net-next v3 05/14] net: dsa: mv88e6xxx: add switch register helpers
The mixed assignments, allocations and registrations in the probe code
make it hard to follow the logic and figure out what is DSA or chip
specific.
Extract the struct dsa_switch related code in a simple
mv88e6xxx_register_switch helper function.
For symmetry in the code, add a mv88e6xxx_unregister_switch function.
Signed-off-by: Vivien Didelot
Reviewed-by: Andrew Lunn
---
drivers/net/dsa/mv88e6xxx.c | 41 -
1 file changed, 28 insertions(+), 13 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 4b4bffc..ad7735d 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -3690,30 +3690,48 @@ static struct dsa_switch_driver mv88e6xxx_switch_driver
= {
.port_fdb_dump = mv88e6xxx_port_fdb_dump,
};
+static int mv88e6xxx_register_switch(struct mv88e6xxx_priv_state *ps,
+struct device_node *np)
+{
+ struct device *dev = ps->dev;
+ struct dsa_switch *ds;
+
+ ds = devm_kzalloc(dev, sizeof(*ds), GFP_KERNEL);
+ if (!ds)
+ return -ENOMEM;
+
+ ds->dev = dev;
+ ds->priv = ps;
+ ds->drv = &mv88e6xxx_switch_driver;
+
+ dev_set_drvdata(dev, ds);
+
+ return dsa_register_switch(ds, np);
+}
+
+static void mv88e6xxx_unregister_switch(struct mv88e6xxx_priv_state *ps)
+{
+ dsa_unregister_switch(ps->ds);
+}
+
static int mv88e6xxx_probe(struct mdio_device *mdiodev)
{
struct device *dev = &mdiodev->dev;
struct device_node *np = dev->of_node;
struct mv88e6xxx_priv_state *ps;
int id, prod_num, rev;
- struct dsa_switch *ds;
u32 eeprom_len;
int err;
- ds = devm_kzalloc(dev, sizeof(*ds) + sizeof(*ps), GFP_KERNEL);
- if (!ds)
+ ps = devm_kzalloc(dev, sizeof(*ps), GFP_KERNEL);
+ if (!ps)
return -ENOMEM;
- ps = (struct mv88e6xxx_priv_state *)(ds + 1);
- ds->priv = ps;
- ds->dev = dev;
ps->dev = dev;
ps->bus = mdiodev->bus;
ps->sw_addr = mdiodev->addr;
mutex_init(&ps->smi_mutex);
- ds->drv = &mv88e6xxx_switch_driver;
-
id = mv88e6xxx_reg_read(ps, REG_PORT(0), PORT_SWITCH_ID);
if (id < 0)
return id;
@@ -3745,9 +3763,7 @@ static int mv88e6xxx_probe(struct mdio_device *mdiodev)
if (err)
return err;
- dev_set_drvdata(dev, ds);
-
- err = dsa_register_switch(ds, np);
+ err = mv88e6xxx_register_switch(ps, np);
if (err) {
mv88e6xxx_mdio_unregister(ps);
return err;
@@ -3764,8 +3780,7 @@ static void mv88e6xxx_remove(struct mdio_device *mdiodev)
struct dsa_switch *ds = dev_get_drvdata(&mdiodev->dev);
struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
- dsa_unregister_switch(ds);
-
+ mv88e6xxx_unregister_switch(ps);
mv88e6xxx_mdio_unregister(ps);
}
--
2.8.3
[RFC nowrap: PATCH v7 00/19] ILP32 for ARM64
This series enables aarch64 with ilp32 mode, and as supporting work,
introduces ARCH_32BIT_OFF_T configuration option that is enabled for
existing 32-bit architectures but disabled for new arches (so 64-bit
off_t is is used by new userspace).
This version is based on kernel v4.7-rc3.
It works with glibc-2.23, and tested with LTP.
This is RFC because there is no solid understanding what type of registers
top-halves delousing we prefer. In this patchset, w0-w7 are cleared for each
syscall in assembler entry. The alternative approach is in introducing compat
wrappers which is little faster for natively routed syscalls (~2.6% for syscall
with no payload) but much more complicated.
v3: https://lkml.org/lkml/2014/9/3/704
v4: https://lkml.org/lkml/2015/4/13/691
v5: https://lkml.org/lkml/2015/9/29/911
v6: https://lkml.org/lkml/2016/5/23/661
v7: RFC nowrap:
- wrappers removed, unconditional register delousing is introduced.
- ino_t, off_t etc are turned to 64-bit.
- added is_compat_thread(),
- fixed ilp32 ELF_PLATFORM MACRO,
- fixed ilp32 ELF_DYN_BASE,
- ptrace redirected to compat version.
- stat, statfs - related syscalls are redirected to native handlers.
- elf_greg_t and elf_gregset_t types are taken from lp64.
- Documentation updated.
Links:
This series:https://github.com/norov/linux/commits/ilp32-nowrap
v7 with wrappers: https://github.com/norov/linux/commits/ilp32
glibc (dirty): https://github.com/norov/glibc/commits/ilp32-nowrap
glibc with wrappers:https://github.com/norov/glibc/commits/ilp32-dev
Andrew Pinski (6):
arm64: ensure the kernel is compiled for LP64
arm64: rename COMPAT to AARCH32_EL0 in Kconfig
arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64
arm64: ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it
arm64: ilp32: introduce ilp32-specific handlers for sigframe and ucontext
arm64:ilp32: add ARM64_ILP32 to Kconfig
Philipp Tomsich (1):
arm64:ilp32: add vdso-ilp32 and use for signal return
Yury Norov (12):
compat ABI: use non-compat openat and open_by_handle_at variants
32-bit ABI: introduce ARCH_32BIT_OFF_T config option
arm64: ilp32: add documentation on the ILP32 ABI for ARM64
thread: move thread bits accessors to separated file
arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat)
arm64: ilp32: add is_ilp32_compat_{task,thread} and TIF_32BIT_AARCH64
arm64: introduce binfmt_elf32.c
arm64: ilp32: introduce binfmt_ilp32.c
arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32
arm64: ilp32: share aarch32 syscall handlers
arm64: signal: share lp64 signal routines to ilp32
arm64: signal32: move ilp32 and aarch32 common code to separated file
Documentation/arm64/ilp32.txt | 54 +++
arch/Kconfig | 4 +
arch/arc/Kconfig | 1 +
arch/arm/Kconfig | 1 +
arch/arm64/Kconfig| 19 ++-
arch/arm64/Makefile | 5 +
arch/arm64/include/asm/compat.h | 19 +--
arch/arm64/include/asm/elf.h | 29 +++-
arch/arm64/include/asm/fpsimd.h | 2 +-
arch/arm64/include/asm/ftrace.h | 2 +-
arch/arm64/include/asm/hwcap.h| 6 +-
arch/arm64/include/asm/is_compat.h| 90
arch/arm64/include/asm/memory.h | 5 +-
arch/arm64/include/asm/processor.h| 11 +-
arch/arm64/include/asm/ptrace.h | 2 +-
arch/arm64/include/asm/signal32.h | 6 +-
arch/arm64/include/asm/signal32_common.h | 25
arch/arm64/include/asm/signal_common.h| 33 +
arch/arm64/include/asm/signal_ilp32.h | 34 +
arch/arm64/include/asm/syscall.h | 2 +-
arch/arm64/include/asm/thread_info.h | 4 +-
arch/arm64/include/asm/unistd.h | 6 +-
arch/arm64/include/asm/unistd32.h | 2 +-
arch/arm64/include/asm/vdso.h | 6 +
arch/arm64/include/uapi/asm/bitsperlong.h | 9 +-
arch/arm64/kernel/Makefile| 14 +-
arch/arm64/kernel/asm-offsets.c | 9 +-
arch/arm64/kernel/binfmt_elf32.c | 31
arch/arm64/kernel/binfmt_ilp32.c | 96 +
arch/arm64/kernel/cpufeature.c| 8 +-
arch/arm64/kernel/cpuinfo.c | 20 +--
arch/arm64/kernel/entry.S | 35 -
arch/arm64/kernel/entry32.S | 65 -
arch/arm64/kernel/entry32_common.S| 93
arch/arm64/kernel/entry_ilp32.S | 23 +++
arch/arm64/kernel/head.S | 2 +-
arch/arm64/kernel/hw_breakpoint.c | 10 +-
arch/arm64/kernel/perf_regs.c | 2 +-
arch/arm64/kernel/process.c
[PATCH v3 net-next v3 09/14] net: dsa: mv88e6xxx: add chip allocation helper
Add an helper function to allocate the chip structure at the beginning
of the probe functions. It will be used to initialize the SMI access.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx.c | 39 +++
1 file changed, 27 insertions(+), 12 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 2c86172..113092a 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -3601,6 +3601,21 @@ static const struct mv88e6xxx_info
*mv88e6xxx_lookup_info(unsigned int prod_num)
return NULL;
}
+static struct mv88e6xxx_priv_state *mv88e6xxx_alloc_chip(struct device *dev)
+{
+ struct mv88e6xxx_priv_state *ps;
+
+ ps = devm_kzalloc(dev, sizeof(*ps), GFP_KERNEL);
+ if (!ps)
+ return NULL;
+
+ ps->dev = dev;
+
+ mutex_init(&ps->reg_lock);
+
+ return ps;
+}
+
static const char *mv88e6xxx_drv_probe(struct device *dsa_dev,
struct device *host_dev, int sw_addr,
void **priv)
@@ -3616,32 +3631,30 @@ static const char *mv88e6xxx_drv_probe(struct device
*dsa_dev,
if (!bus)
return NULL;
+ ps = mv88e6xxx_alloc_chip(dsa_dev);
+ if (!ps)
+ return NULL;
+
id = __mv88e6xxx_reg_read(bus, sw_addr, REG_PORT(0), PORT_SWITCH_ID);
if (id < 0)
- return NULL;
+ goto free;
prod_num = (id & 0xfff0) >> 4;
rev = id & 0x000f;
info = mv88e6xxx_lookup_info(prod_num);
if (!info)
- return NULL;
+ goto free;
name = info->name;
- ps = devm_kzalloc(dsa_dev, sizeof(*ps), GFP_KERNEL);
- if (!ps)
- return NULL;
-
ps->bus = bus;
ps->sw_addr = sw_addr;
ps->info = info;
- ps->dev = dsa_dev;
- mutex_init(&ps->reg_lock);
err = mv88e6xxx_mdio_register(ps, NULL);
if (err)
- return NULL;
+ goto free;
*priv = ps;
@@ -3649,6 +3662,10 @@ static const char *mv88e6xxx_drv_probe(struct device
*dsa_dev,
prod_num, name, rev);
return name;
+free:
+ devm_kfree(dsa_dev, ps);
+
+ return NULL;
}
static struct dsa_switch_driver mv88e6xxx_switch_driver = {
@@ -3720,14 +3737,12 @@ static int mv88e6xxx_probe(struct mdio_device *mdiodev)
u32 eeprom_len;
int err;
- ps = devm_kzalloc(dev, sizeof(*ps), GFP_KERNEL);
+ ps = mv88e6xxx_alloc_chip(dev);
if (!ps)
return -ENOMEM;
- ps->dev = dev;
ps->bus = mdiodev->bus;
ps->sw_addr = mdiodev->addr;
- mutex_init(&ps->reg_lock);
id = mv88e6xxx_reg_read(ps, REG_PORT(0), PORT_SWITCH_ID);
if (id < 0)
--
2.8.3
[PATCH v3 net-next v3 11/14] net: dsa: mv88e6xxx: add detection helper
Extract the common detection code which assigns the info structure to
the chip given the read switch ID.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx.c | 64 +
1 file changed, 30 insertions(+), 34 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 4e24ac5..de92add 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -3601,6 +3601,30 @@ static const struct mv88e6xxx_info
*mv88e6xxx_lookup_info(unsigned int prod_num)
return NULL;
}
+static int mv88e6xxx_detect(struct mv88e6xxx_priv_state *ps)
+{
+ const struct mv88e6xxx_info *info;
+ int id, prod_num, rev;
+
+ id = mv88e6xxx_reg_read(ps, REG_PORT(0), PORT_SWITCH_ID);
+ if (id < 0)
+ return id;
+
+ prod_num = (id & 0xfff0) >> 4;
+ rev = id & 0x000f;
+
+ info = mv88e6xxx_lookup_info(prod_num);
+ if (!info)
+ return -ENODEV;
+
+ ps->info = info;
+
+ dev_info(ps->dev, "switch 0x%x detected: %s, revision %u\n",
+ps->info->prod_num, ps->info->name, rev);
+
+ return 0;
+}
+
static struct mv88e6xxx_priv_state *mv88e6xxx_alloc_chip(struct device *dev)
{
struct mv88e6xxx_priv_state *ps;
@@ -3633,11 +3657,8 @@ static const char *mv88e6xxx_drv_probe(struct device
*dsa_dev,
struct device *host_dev, int sw_addr,
void **priv)
{
- const struct mv88e6xxx_info *info;
struct mv88e6xxx_priv_state *ps;
struct mii_bus *bus;
- const char *name;
- int id, prod_num, rev;
int err;
bus = dsa_host_dev_to_mii_bus(host_dev);
@@ -3652,31 +3673,17 @@ static const char *mv88e6xxx_drv_probe(struct device
*dsa_dev,
if (err)
goto free;
- id = mv88e6xxx_reg_read(ps, REG_PORT(0), PORT_SWITCH_ID);
- if (id < 0)
- goto free;
-
- prod_num = (id & 0xfff0) >> 4;
- rev = id & 0x000f;
-
- info = mv88e6xxx_lookup_info(prod_num);
- if (!info)
+ err = mv88e6xxx_detect(ps);
+ if (err)
goto free;
- name = info->name;
-
- ps->info = info;
-
err = mv88e6xxx_mdio_register(ps, NULL);
if (err)
goto free;
*priv = ps;
- dev_info(&ps->bus->dev, "switch 0x%x probed: %s, revision %u\n",
-prod_num, name, rev);
-
- return name;
+ return ps->info->name;
free:
devm_kfree(dsa_dev, ps);
@@ -3748,7 +3755,6 @@ static int mv88e6xxx_probe(struct mdio_device *mdiodev)
struct device *dev = &mdiodev->dev;
struct device_node *np = dev->of_node;
struct mv88e6xxx_priv_state *ps;
- int id, prod_num, rev;
u32 eeprom_len;
int err;
@@ -3760,16 +3766,9 @@ static int mv88e6xxx_probe(struct mdio_device *mdiodev)
if (err)
return err;
- id = mv88e6xxx_reg_read(ps, REG_PORT(0), PORT_SWITCH_ID);
- if (id < 0)
- return id;
-
- prod_num = (id & 0xfff0) >> 4;
- rev = id & 0x000f;
-
- ps->info = mv88e6xxx_lookup_info(prod_num);
- if (!ps->info)
- return -ENODEV;
+ err = mv88e6xxx_detect(ps);
+ if (err)
+ return err;
ps->reset = devm_gpiod_get_optional(dev, "reset", GPIOD_ASIS);
if (IS_ERR(ps->reset))
@@ -3789,9 +3788,6 @@ static int mv88e6xxx_probe(struct mdio_device *mdiodev)
return err;
}
- dev_info(dev, "switch 0x%x probed: %s, revision %u\n",
-prod_num, ps->info->name, rev);
-
return 0;
}
--
2.8.3
[PATCH v3 net-next v3 03/14] net: dsa: mv88e6xxx: use already declared variables
In the MDIO probing function, dev is already assigned to &mdiodev->dev
and np is already assigned to mdiodev->dev.of_node, so use them.
Signed-off-by: Vivien Didelot
Reviewed-by: Andrew Lunn
---
drivers/net/dsa/mv88e6xxx.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 673283a..b3170ea 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -3728,7 +3728,7 @@ static int mv88e6xxx_probe(struct mdio_device *mdiodev)
if (!ps->info)
return -ENODEV;
- ps->reset = devm_gpiod_get(&mdiodev->dev, "reset", GPIOD_ASIS);
+ ps->reset = devm_gpiod_get(dev, "reset", GPIOD_ASIS);
if (IS_ERR(ps->reset)) {
err = PTR_ERR(ps->reset);
if (err == -ENOENT) {
@@ -3743,13 +3743,13 @@ static int mv88e6xxx_probe(struct mdio_device *mdiodev)
!of_property_read_u32(np, "eeprom-length", &eeprom_len))
ps->eeprom_len = eeprom_len;
- err = mv88e6xxx_mdio_register(ps, mdiodev->dev.of_node);
+ err = mv88e6xxx_mdio_register(ps, np);
if (err)
return err;
dev_set_drvdata(dev, ds);
- err = dsa_register_switch(ds, mdiodev->dev.of_node);
+ err = dsa_register_switch(ds, np);
if (err) {
mv88e6xxx_mdio_unregister(ps);
return err;
--
2.8.3
