On Fri, 2017-12-08 at 14:02 -0800, Andrew Morton wrote:
> On Fri, 8 Dec 2017 19:33:15 +0900 Sergey Senozhatsky
> wrote:
>
> > On (12/08/17 17:37), Liu, Changcheng wrote:
> > >
> > > On some linux distributions, the default link of sh
> > > is dash which deoesn't support split array like
> > > $
On Thu, Dec 7, 2017 at 2:36 AM, Yangbo Lu wrote:
> This patch is to add compatible strings "fsl,ls1021a-dcfg" and
> "fsl,ls1043a-dcfg" into device match table of GUTS driver.
>
> Signed-off-by: Yangbo Lu
> ---
> drivers/soc/fsl/guts.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/dr
On Fri, 8 Dec 2017 11:56:07 +0900 Sergey Senozhatsky
wrote:
> A small patch set that removes some kallsyms includes
> here and there. Mostly those kallsyms includes are leftovers:
> printk() gained %pS/%pF modifiers support some time ago, so
> print_symbol() and friends became sort of unn
Luck, Tony wrote:
> I pulled this branch and it builds on all of my ia64 test
> configurations. Boots too.
>
> So no ia64 breakage.
Excellent, thanks! Can I put you down as a Tested-by?
David
> Excellent, thanks! Can I put you down as a Tested-by?
Yes
Tested-by: Tony Luck
From: Thomas Gleixner
The LDT is inheritet independent of fork or exec, but that makes no sense
at all because exec is supposed to start the process clean.
The reason why this happens is that init_new_context_ldt() is called from
init_new_context() which obviously needs to be called for both for
LDT should not be inherited on exec(), only on fork().
To sanitize that, the LDT initialization for a new process must be split
into parts and the actual duplication moved to arch_dup_mmap() which is
only called on fork(). This requires that arch_dup_mmap() gains a return
value.
Changes vs. V1:
In order to sanitize the LDT initialization on x86 arch_dup_mmap() must be
allowed to fail Fix up all instances.
Signed-off-by: Thomas Gleixner
---
arch/powerpc/include/asm/mmu_context.h |5 +++--
arch/um/include/asm/mmu_context.h|3 ++-
arch/unicore32/include/asm/mmu_context.h
On Fri, Dec 08, 2017 at 12:35:07PM -0500, Alan Stern wrote:
> On Fri, 8 Dec 2017, Byungchul Park wrote:
>
> > I'm sorry to hear that.. If I were you, I would also get
> > annoyed. And.. thanks for explanation.
> >
> > But, I think assigning lock classes properly and checking
> > relationship of t
On Fri, 1 Dec 2017 16:53:03 +0900 js1...@gmail.com wrote:
> From: Joonsoo Kim
>
> v2
> o previous failure in linux-next turned out that it's not the problem of
> this patchset. It was caused by the wrong assumption by specific
> architecture.
>
> lkml.kernel.org/r/20171114173719.ga28...@atomid
This patchset adds support for Perf Extension on AMD KVM guests.
When perf runs on a guest with family = 15h || 17h, the MSRs that are
accessed, when the Perf Extension flag is made available, differ from
the existing K7 MSRs. The accesses are to the AMD Core Performance
Extension counters which p
Add the EventSelect and Counter MSRs for AMD Core Perf Extension.
Signed-off-by: Janakarajan Natarajan
---
arch/x86/include/asm/msr-index.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 34c4922..93ad9
Expose the AMD Core Perf Extension flag to the guests.
Signed-off-by: Janakarajan Natarajan
---
arch/x86/kvm/cpuid.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 0099e10..8c95a7c 100644
--- a/arch/x86/kvm/cpuid.c
+++
Add support for AMD Core Performance counters in the guest. The base
event select and counter MSRs are changed. In addition, with the core
extension, there are 2 extra counters available for performance
measurements for a total of 6.
With the new MSRs, the logic to map them to the gp_counters[] is
On Fri, Dec 08, 2017 at 10:14:38AM -0800, Matthew Wilcox wrote:
> At the moment, the radix tree actively disables the RCU checking that
> enabling lockdep would give us. It has to, because it has no idea what
> lock protects any individual access to the radix tree. The XArray can
> use the RCU ch
On Fri, 8 Dec 2017, Ville Syrjälä wrote:
> On Fri, Dec 08, 2017 at 05:33:23PM +0800, Augustine.Chen wrote:
> > The chip data of HDMI LPE audio is set to drm_i915_private which is not
> > consistent with the expectation by x86 APIC driver.
>
> Hmm. Why is the apic code looking at data for an irq c
On Fri, 8 Dec 2017 13:47:58 -0800
Jeff Kirsher wrote:
> From: Liang-Min Wang
>
> When a SR-IOV capable device is bound with vfio-pci, the
> device loses capability of creating SR-IOV instances through /sy/bus/
> pci/devices/.../sriov_numvfs. This patch re-activates this capability
> for a PCIe
Matthew,
On Thu, 7 Dec 2017, Matthew Auld wrote:
Can you please add a version number to your patches? Having the same
subject line five times is just annoying.
> From: Joonas Lahtinen
> To give upcoming SKU BIOSes more flexibility in placing the Intel
> graphics stolen memory, make all variab
On 11/07/2017 09:53 AM, Shuah Khan wrote:
> On 10/16/2017 09:18 AM, Hans Verkuil wrote:
>> On 10/16/2017 05:16 PM, Shuah Khan wrote:
>>> The driver mmap functions shouldn't take lock when calling vb2_mmap().
>>> Fix it to not take the lock.
>>>
>>> Reference: commit log for f035eb4e976ef5a059e30bc9
On Thu, Dec 07, 2017 at 11:38:43AM +1100, Dave Chinner wrote:
> > > cmpxchg is for replacing a known object in a store - it's not really
> > > intended for doing initial inserts after a lookup tells us there is
> > > nothing in the store. The radix tree "insert only if empty" makes
> > > sense her
On Fri, 8 Dec 2017 12:40:17 -0800
Jacob Pan wrote:
> On Fri, 8 Dec 2017 13:52:00 +
> Jean-Philippe Brucker wrote:
>
> > On 07/12/17 21:51, Alex Williamson wrote:
> > >> Agree, IOMMU driver cannot enforce it. I think VFIO layer can make
> > >> sure page response come from the assigned devi
On Thu, 7 Dec 2017, Matthew Auld wrote:
> Makes things a little easier to follow.
I disagree. The comment explains gms (what ever that is) in ascending order
and the code has that implemented the same way. Now you change the code to
descending order.
How is that easier to follow? Not at all. Tha
The new notify_handler logic determining if autorelease should be used or
not is a bit awkward, and can result in more than one call to
sparse_keymap_report_event for the same event (scancode). The nesting
and long lines also made it difficult to read.
Simplify the logic by eliminating a level of
On Fri, Dec 8, 2017 at 2:58 PM, Alex Williamson
wrote:
> On Fri, 8 Dec 2017 13:47:58 -0800
> Jeff Kirsher wrote:
>
>> From: Liang-Min Wang
>>
>> When a SR-IOV capable device is bound with vfio-pci, the
>> device loses capability of creating SR-IOV instances through /sy/bus/
>> pci/devices/.../s
On 12/08/2017 09:24 PM, Josef Bacik wrote:
> On Fri, Dec 08, 2017 at 04:35:44PM +0100, Daniel Borkmann wrote:
>> On 12/06/2017 05:12 PM, Josef Bacik wrote:
>>> Jon noticed that I had a typo in my _ASM_KPROBE_ERROR_INJECT macro. I went
>>> to
>>> figure out why the compiler didn't catch it and it'
On Fri, 8 Dec 2017 13:08:37 -0700
Jens Axboe wrote:
> On 12/08/2017 08:38 AM, Michele Ballabio wrote:
> > Hi,
> > kernels 4.13.*, 4.14.* 4.15-rc2 crash on occasion,
> > especially on x86-32 systems. To trigger the problem, run as root:
> >
> > while true
> > do
> > /sbin/udevadm trig
Fixed braces, double empty lines, tabs and spaces
and a macro with checkpatch.
Signed-off-by: Peter Johennecken
---
drivers/staging/pi433/pi433_if.c | 242 +++--
drivers/staging/pi433/pi433_if.h | 13 +-
drivers/staging/pi433/rf69.c | 66 ---
drive
On Saturday, December 9, 2017 12:07:08 AM CET Darren Hart (VMware) wrote:
> The new notify_handler logic determining if autorelease should be used or
> not is a bit awkward, and can result in more than one call to
> sparse_keymap_report_event for the same event (scancode). The nesting
> and long li
On 12/05/2017 12:59 PM, Bjorn Helgaas wrote:
> On Tue, Nov 14, 2017 at 05:12:05PM -0500, Jim Quinlan wrote:
>> From: Florian Fainelli
>>
>> This commit adds a memory API suitable for ascertaining the sizes of
>> each of the N memory controllers in a Broadcom STB chip. Its first
>> user will be
On Fri, 8 Dec 2017 09:52:16 -0700, David Ahern wrote:
> On 12/8/17 8:39 AM, Quentin Monnet wrote:
> > I don't believe compatibility is an issue here, since the program and
> > its documentation come together (so they should stay in sync) and are
> > part of the kernel tree (so the tool should be co
On Fri, 8 Dec 2017 15:19:18 -0800
Alexander Duyck wrote:
> On Fri, Dec 8, 2017 at 2:58 PM, Alex Williamson
> wrote:
> > On Fri, 8 Dec 2017 13:47:58 -0800
> > Jeff Kirsher wrote:
> >
> >> From: Liang-Min Wang
> >>
> >> When a SR-IOV capable device is bound with vfio-pci, the
> >> device lose
Linus,
On Fri, Dec 8, 2017 at 10:16 PM, Linus Torvalds
wrote:
> On Thu, Dec 7, 2017 at 5:20 PM, Dave Airlie wrote:
>>
>> This pull is a bit larger than I'd like but a large bunch of it is
>> license fixes, AMD wanted to fix the licenses for a bunch of files
>> that were missing them,
>
> Oh Chri
On Sat, Dec 02, 2017 at 09:45:33PM +0800, Jiaxun Yang wrote:
> To deal with checkpatch warnings:
> WARNING: Prefer kstrto to single variable sscanf
>
> WARNING: Missing a blank line after declarations
>
> WARNING: Block comments use a trailing */ on a separate line
>
> Signed-off-by: Jiaxun Yang
On Sat, Dec 02, 2017 at 09:45:31PM +0800, Jiaxun Yang wrote:
> To deal with checkpatch warning:
> WARNING: else is not generally useful after a break or return
>
Patches 1,2, and 4 queued for testing. Thanks. See comments in 3 of 4.
--
Darren Hart
VMware Open Source Technology Center
On Fri, 8 Dec 2017 14:52:36 +, Roman Gushchin wrote:
> +static int list_attached_bpf_progs(int cgroup_fd, enum bpf_attach_type type)
> +{
> + __u32 prog_ids[1024] = {0};
> + char *attach_flags_str;
> + __u32 prog_cnt, iter;
> + __u32 attach_flags;
> + char buf[16];
> + i
On Sat, Dec 09, 2017 at 12:28:18AM +0100, Stefan Brüns wrote:
> On Saturday, December 9, 2017 12:07:08 AM CET Darren Hart (VMware) wrote:
> > The new notify_handler logic determining if autorelease should be used or
> > not is a bit awkward, and can result in more than one call to
> > sparse_keymap
On Fri, Dec 08, 2017 at 01:08:37PM -0700, Jens Axboe wrote:
> On 12/08/2017 08:38 AM, Michele Ballabio wrote:
> > Hi,
> > kernels 4.13.*, 4.14.* 4.15-rc2 crash on occasion, especially
> > on x86-32 systems. To trigger the problem, run as root:
> >
> > while true
> > do
> > /sbin/udevad
On (12/08/17 11:53), Bjorn Helgaas wrote:
> On Fri, Dec 08, 2017 at 11:56:11AM +0900, Sergey Senozhatsky wrote:
> > The file was converted from print_fn_descriptor_symbol()
> > to %pF some time ago (c9bbb4abb658da "PCI: use %pF instead
> > of print_fn_descriptor_symbol() in quirks.c"). kallsyms doe
On (12/08/17 14:02), Andrew Morton wrote:
> > On (12/08/17 17:37), Liu, Changcheng wrote:
> > >
> > > On some linux distributions, the default link of sh
> > > is dash which deoesn't support split array like
> > > ${var//,/ }
> > > It's better to force to use bash shell directly.
> > >
> > > Sign
From: Colin Ian King
The initialization of pcc_ss_data from pcc_data[pcc_ss_id] before
pcc_ss_id is being range checked could lead to an out-of-bounds array
read. This very same initialization is also being performed after
the range check on pcc_ss_id, so we can just remove this problematic
and
On (12/08/17 14:24), Andrew Morton wrote:
> On Fri, 8 Dec 2017 11:56:07 +0900 Sergey Senozhatsky
> wrote:
>
> > A small patch set that removes some kallsyms includes
> > here and there. Mostly those kallsyms includes are leftovers:
> > printk() gained %pS/%pF modifiers support some time ago
At present, ntb_netdev devices end up under /sys/devices/virtual/net
completely unconnected to the ntb trees below them. This patch sets the
parent of the net_device (using SET_NETDEV_DEV) to the client_dev
device. This results in a better connected sysfs path for the network
device:
/sys/devices/
Sorry ignore this. I sent an old patch :(
Logan
On 08/12/17 05:01 PM, Logan Gunthorpe wrote:
At present, ntb_netdev devices end up under /sys/devices/virtual/net
completely unconnected to the ntb trees below them. This patch sets the
parent of the net_device (using SET_NETDEV_DEV) to the client
In cases where there are more mw's than spads/2-2, the mw count gets
reduced to match the limitation. ntb_transport also tries to ensure that
there are fewer qps than mws but uses the full mw count instead of
the reduced one. When this happens, the math in
'ntb_transport_setup_qp_mw' will get confu
On Fri, Dec 08, 2017 at 06:30:34PM +, Ard Biesheuvel wrote:
> Commit be55287aa5b ("drm/nouveau/imem/nv50: embed nvkm_instobj directly
> into nv04_instobj") introduced some new calls to the refcount api to
> the nv50 mapping code. In one particular instance, it does the
> following:
>
> if
When using the max_mw_size parameter of ntb_transport to limit the size of
the Memory windows, communication cannot be established and the queues
freeze.
This is because the mw_size that's reported to the peer is correctly
limited but the size used locally is not. So the MW is initialized
with a b
With Switchtec hardware, the buffer used for a memory window must be
aligned to its size (the hardware only replaces the lower bits). In
certain circumstances dma_alloc_coherent() will not provide a buffer
that adheres to this requirement like when using the CMA and
CONFIG_CMA_ALIGNMENT is set lowe
Sorry, ignore this. I sent an old patch.
Logan
On 08/12/17 05:01 PM, Logan Gunthorpe wrote:
In cases where there are more mw's than spads/2-2, the mw count gets
reduced to match the limitation. ntb_transport also tries to ensure that
there are fewer qps than mws but uses the full mw count inste
The mm-of-the-moment snapshot 2017-12-08-16-01 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You wi
On Mon, Dec 04, 2017 at 10:26:17AM +1000, Peter Hutterer wrote:
> Sending the switch state change twice within the same frame is invalid evdev
> protocol and only works if the client handles keys immediately as well.
> Processing events immediately is incorrect, it forces a fake order of events
> t
On 12/08, Abhishek Sahu wrote:
> On 2017-12-07 11:53, Stephen Boyd wrote:
> >On 09/28, Abhishek Sahu wrote:
> >>This patch series does the miscellaneous changes in QCOM Alpha PLL
> >>operation and structure to support other types of Alpha PLL’s.
> >>
> >>1. It adds the pll_type which will be used f
Sali,
On Fri, Dec 8, 2017 at 10:16 PM, Salil Mehta wrote:
> This patch adds the support of the mailbox to the VF driver. The
> mailbox shall be used as an interface to communicate with the
> PF driver for various purposes like {set|get} MAC related
> operations, reset, link status etc. The mailbo
On 09/28, Abhishek Sahu wrote:
> Some of the divider settings are preconfigured and should not
> be changed by the clock framework during frequency change. This
> patch adds the read-only divider operation for QCOM alpha pll
> post divider which is equivalent to generic divider operations in
> 'com
On 09/28, Abhishek Sahu wrote:
> Alpha PLL is a generic name used for QCOM PLL’s which uses L
> and Alpha values for configuring the integer and fractional part.
> QCOM SoC’s use different types of Alpha PLL’s for which basic
> software configuration part is common with following differences.
>
>
On 09/28, Abhishek Sahu wrote:
> Some of the Alpha PLL’s support dynamic update in which the
> frequency can be changed dynamically without turning off the PLL.
>
> This dynamic update requires the following sequence
>
> 1. Write the desired values to pll_l_val and pll_alpha_val
> 2. Toggle pll_l
On 09/28, Abhishek Sahu wrote:
> The alpha value calculation function has been written for 40 bit
> alpha which is not coming properly for 16 bit
>
> 1. Alpha value is being calculated on the basis of
>ALPHA_BITWIDTH to make the computation easy for 40 bit alpha.
>After calculating the 32
On 09/28, Abhishek Sahu wrote:
> The current configuration does not fully configure PLL alpha mode
> and values so this patch
>
> 1. Configures PLL_ALPHA_VAL_U for PLL which supports 40 bit alpha.
> 2. Adds alpha enable and alpha mode configuration support.
>
> Signed-off-by: Abhishek Sahu
> ---
On 09/28, Abhishek Sahu wrote:
> Currently SUPPORTS_16BIT_ALPHA flag determines the PLL alpha
> register width. If this flag is set then the alpha register width
> is 16 bits otherwise it is 40 bits. The alpha width is always
> fixed for PLL type so it can be added in PLL properties and clock
> dri
On 09/28, Abhishek Sahu wrote:
> Some of the Alpha PLL’s (like Spark, Brammo PLL) do not have
> CONFIG_CTL_U register. This patch adds the flag in properties
> for PLL’s which have CONFIG_CTL_U register and checks the same
> while doing PLL initial configuration.
>
> Signed-off-by: Abhishek Sahu
On 09/28, Abhishek Sahu wrote:
> Current PLL driver only supports 4 bit PLL post divider so
> modified the PLL divider operations to support 2 bit PLL
> post divider.
>
> Signed-off-by: Abhishek Sahu
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
On 09/28, Abhishek Sahu wrote:
> 1. Brammo PLL does not allow configuration of VCO
> 2. Supports the dynamic update in which the frequency can
>be changed dynamically without turning off the PLL
> 3. The register offsets are different from normal Alpha PLL
>
> Signed-off-by: Abhishek Sahu
> -
On 09/28, Abhishek Sahu wrote:
> Some of the Alpha PLL’s does not have VCO configuration so this
> patch adds the flag and does not perform VCO operation if this
> flag is set.
>
> Signed-off-by: Abhishek Sahu
> ---
Applied to clk-next
--
Qualcomm Innovation Center, Inc. is a member of Code Au
On 09/28, Abhishek Sahu wrote:
> Following are the major differences in Huayra PLL
>
> 1. PLL Alpha Value is 16 bits
> 2. Depending on alpha_mode, the pll_alpha_val can be treated as
>M/N value or as a two’s compliment number.
> 3. Huayra PLL supports PLL dynamic programming. User can change
>
From: Fenghua Yu
With more flag bits in /proc/cpuinfo for RDT, it's better to classify the
bits for readability.
Some previously missing bits are added as well.
Signed-off-by: Fenghua Yu
---
Documentation/x86/intel_rdt_ui.txt | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff -
From: Colin Ian King
The check for secs being less than zero is redundant for two reasons.
Firstly, secs is unsigned so the check is always going to be false.
Secondly, if secs was signed the proceeding calculation of secs is
never going to be negative. Hence we can remove this redundant check
a
The purpose of pushing indication on a list and handle these in a
separate worker is to allow the handlers to sleep. It does therefor not
make much sense to hold the queue spinlock through the entire indication
worker function.
By removing items from the queue early we don't need to hold the lock
2017-12-09 0:28 GMT+08:00 David Miller :
> From: Yafang Shao
> Date: Fri, 8 Dec 2017 23:50:44 +0800
>
>> 2017-12-08 23:42 GMT+08:00 David Miller :
>>> From: Yafang Shao
>>> Date: Fri, 8 Dec 2017 11:40:23 +0800
>>>
It will looks like these,
if (sk->sk_protocol == IPPROTO_TCP)
>>
From: "Darren Hart (VMware)"
uaddr alignment is currently tested by get_futex_key(). We can catch
misalignment earlier in sys_futex and return -EINVAL sooner. This
simplifies get_futex_key() a little, but more importantly exits the
kernel as soon as an invalid parameter is detected.
Passes all s
In trying to add support for drm_hwcomposer to HiKey,
I've needed to utilize the ION CMA heap, and I've noticed
problems with allocations on newer kernels failing.
It seems back with 204f672255c2 ("ion: Use CMA APIs directly"),
the ion_cma_heap code was modified to use the CMA API, but
kept the ar
do_sea() calls arm64_notify_die() which will always signal
user-space. It also returns whether APEI claimed the external
abort as a RAS notification. If it returns failure do_mem_abort()
will signal user-space too.
do_mem_abort() wants to know if we handled the error, we always
call arm64_notify_d
Hi Mylène,
On Fri, Dec 08, 2017 at 10:54:18PM +0100, Mylène Josserand wrote:
> Add the support of regulator to use them as VCC source.
>
> Signed-off-by: Mylène Josserand
> ---
> drivers/input/touchscreen/edt-ft5x06.c | 33 +
> 1 file changed, 33 insertions(+)
>
On Fri, Dec 08, 2017 at 08:42:52AM +0100, Greg Kroah-Hartman wrote:
> On Fri, Dec 08, 2017 at 10:27:51AM +1100, Tobin C. Harding wrote:
> > From: Joe Perches
> >
> > Recently signature tag Co-Developed-by was added to the
> > kernel (Documentation/process/5.Posting.rst). checkpatch.pl doesn't kno
On Fri, Dec 08, 2017 at 05:16:29PM -0800, Dmitry Torokhov wrote:
> Hi Mylène,
>
> On Fri, Dec 08, 2017 at 10:54:18PM +0100, Mylène Josserand wrote:
> > Add the support of regulator to use them as VCC source.
> >
> > Signed-off-by: Mylène Josserand
> > ---
> > drivers/input/touchscreen/edt-ft5x0
On Fri, Dec 08, 2017 at 01:22:37PM -0800, Joe Perches wrote:
> On Fri, 2017-12-08 at 13:06 -0800, Kees Cook wrote:
> > Well ... my sense is that lib/vsprintf.c should remain the canonical
> > documentation.
>
> I agree.
>
> > Anyone working on the code has the docs all together in
> > one file. I
In preparation of moving to the common clock framework, usage of static
struct clk_lookup is removed. The common clock framework uses an opaque
struct clk, so we won't be able to use static tables as was previously
done.
davinci_clk_init() is changed to init a single clock instead of a table.
Sig
This series takes the first steps towards moving mach-davinci to the common
clock framework.
Basically, this series does some cleanup and rearranging to get things
ready for the conversion. Then in "ARM: davinci: convert to common clock
framework" we actually make the conversion. This is done by j
This removed the debugfs entry for mach-davinci clocks. The clocks now use
the common clock framework, which provides debugfs already, so this code is
redundant.
Signed-off-by: David Lechner
---
v2 changes: None
arch/arm/mach-davinci/clock.c | 79 ---
1
This converts the clocks in mach-davinci to the common clock framework.
Most of the patch just involves renaming struct clk to struct davinci_clk.
There is also a struct clk_hw added to provide the bridge between the
existing clock implementation and the common clock framework.
The clk_get_parent
This makes davinci_clk_reset() static. It is not used anywhere else.
Signed-off-by: David Lechner
---
v2 changes: None
arch/arm/mach-davinci/clock.c | 3 +--
arch/arm/mach-davinci/clock.h | 1 -
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/mach-davinci/clock.c b/arch/
This moves the call of davinci_clk_init() from map_io to init_time for all
boards.
This is the proper place to init clocks. This is also done in preparation
for moving to the common clock framework.
Signed-off-by: David Lechner
---
v2 changes:
* Introduce new init_time function for each SoC ins
On 12/08/2017 07:43 PM, David Lechner wrote:
In preparation of moving to the common clock framework, usage of static
struct clk_lookup is removed. The common clock framework uses an opaque
struct clk, so we won't be able to use static tables as was previously
done.
davinci_clk_init() is changed
On 12/8/2017 8:54 AM, Rafael J. Wysocki wrote:
>> static int ged_remove(struct platform_device *pdev)
>> +{
>> + struct acpi_ged_device *geddev = platform_get_drvdata(pdev);
>>
>> + ged_cleanup_irq(geddev);
> Do you really need this duplication? You may as well call
> ged_shutdown() fr
In preparation of moving to the common clock framework, usage of static
struct clk_lookup is removed. The common clock framework uses an opaque
struct clk, so we won't be able to use static tables as was previously
done.
davinci_clk_init() is changed to init a single clock instead of a table.
Sig
This removed the debugfs entry for mach-davinci clocks. The clocks now use
the common clock framework, which provides debugfs already, so this code is
redundant.
Signed-off-by: David Lechner
---
arch/arm/mach-davinci/clock.c | 79 ---
1 file changed, 79 de
This series takes the first steps towards moving mach-davinci to the common
clock framework.
Basically, this series does some cleanup and rearranging to get things
ready for the conversion. Then in "ARM: davinci: convert to common clock
framework" we actually make the conversion. This is done by j
This moves the call of davinci_clk_init() from map_io to init_time for all
boards.
This is the proper place to init clocks. This is also done in preparation
for moving to the common clock framework.
Signed-off-by: David Lechner
---
arch/arm/mach-davinci/board-da830-evm.c | 2 +-
arch/arm/m
This converts the clocks in mach-davinci to the common clock framework.
Most of the patch just involves renaming struct clk to struct davinci_clk.
There is also a struct clk_hw added to provide the bridge between the
existing clock implementation and the common clock framework.
The clk_get_parent
This makes davinci_clk_reset() static. It is not used anywhere else.
Signed-off-by: David Lechner
---
arch/arm/mach-davinci/clock.c | 3 +--
arch/arm/mach-davinci/clock.h | 1 -
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/mach-davinci/clock.c b/arch/arm/mach-davinci/cl
On Sat, 2017-12-09 at 12:27 +1100, Tobin C. Harding wrote:
> On Fri, Dec 08, 2017 at 01:22:37PM -0800, Joe Perches wrote:
> > Outside of the documentation, what could be useful is for
> > someone to add a tool to verify %p extension to
> > the typeof address actually passed as an argument.
>
> Th
It's possible for the same GUID to show up on as system twice.
This means using solely the GUID for identify the file will not
be sufficient.
Signed-off-by: Mario Limonciello
---
drivers/platform/x86/wmi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/x86
I recently discovered that multiple instances of the WMI BMOF
GUID are present on some machines with more advanced WMI implementations.
Only the first found instance is parsed today with the rest ignored.
The rest of the instances should be readable by the wmi-bmof driver
(and userspace) to allow
In: commit d1f9e4970742 ("ACPI: WMI: Survive BIOS with duplicate GUIDs")
parsing two of the same GUID was prevented in the WMI bus driver.
At the time no one understood why GUID 05901221-D566-11D1-B2F0-00A0C9062910
was being duplicated. It's now known that GUID is used for the binary
MOF file of
--Andy
> On Dec 8, 2017, at 6:34 PM, Mario Limonciello
> wrote:
>
> It's possible for the same GUID to show up on as system twice.
> This means using solely the GUID for identify the file will not
> be sufficient.
Isn't the file already in a per-bus directory?
From: Andrew Waterman
RISC-V systems perform TLB shootdows via the SBI, which currently
performs an IPI to each of the remote harts which then performs a local
TLB flush. This process is a bit on the slow side, but we can at least
speed it up for some common cases by restricting the set of harts
On Fri, Dec 8, 2017 at 1:02 PM, David Rientjes wrote:
> On Thu, 7 Dec 2017, Suren Baghdasaryan wrote:
>
>> Slab shrinkers can be quite time consuming and when signal
>> is pending they can delay handling of the signal. If fatal
>> signal is pending there is no point in shrinking that process
>> si
On Fri, Dec 08, 2017 at 09:27:37AM +0100, Michal Hocko wrote:
> On Fri 08-12-17 12:42:55, changbin...@intel.com wrote:
> > From: Changbin Du
> >
> > This patch introduced 4 new interfaces to allocate a prepared transparent
> > huge page. These interfaces merge distributed two-step allocation as s
On Thu, Dec 7, 2017 at 1:07 PM, Greg Kroah-Hartman
wrote:
> This is the start of the stable review cycle for the 4.14.5 release.
> There are 75 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Resp
>> On Dec 8, 2017, at 6:34 PM, Mario Limonciello
>> wrote:
>>
>> It's possible for the same GUID to show up on as system twice.
>> This means using solely the GUID for identify the file will not
>> be sufficient.
>
>Isn't the file already in a per-bus directory?
Yep, but the symlink created in /
Hello,
I'm Mr. Hazim, A banker working in a bank in my country; there is a certain
deceased customer of my bank who left behind her fund.
I seek your partnership in receiving this fund. If interested, reply
immediately for detailed information.
My sincere regards, Mr. Hazim Issa.
On Fri 08 Dec 09:22 PST 2017, Charles Keepax wrote:
> On Fri, Dec 08, 2017 at 03:40:49PM +0100, Linus Walleij wrote:
> > On Fri, Dec 8, 2017 at 3:29 PM, Charles Keepax
> > wrote:
> >
> > > (...) I have finally
> > > managed to get some time to look over the pinctrl-single stuff.
> > >
> > > Naiv
801 - 900 of 935 matches
Mail list logo
