On Sat, Dec 9, 2017 at 7:45 AM, Greg Kroah-Hartman
wrote:
> On Sat, Dec 09, 2017 at 03:34:24AM +, Ivan Kozik wrote:
>> I saw no problems on 8 of 9 machines, but the last one had a problem
>> because it used NVIDIA drivers (387); DKMS reported:
>>
>> FATAL: modpost: GPL-incompatible module nvid
> On 27. Nov 2017, at 14:09, Steve Rutherford wrote:
>
> On Mon, Nov 27, 2017 at 3:58 AM, Paolo Bonzini wrote:
>> On 26/11/2017 17:41, Filippo Sironi wrote:
>>> ... that the guest should see.
>>> Guest operating systems may check the microcode version to decide whether
>>> to disable certain fe
On Sat, Dec 09, 2017 at 03:34:24AM +, Ivan Kozik wrote:
> 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 h
> On 27. Nov 2017, at 03:58, Paolo Bonzini wrote:
>
> On 26/11/2017 17:41, Filippo Sironi wrote:
>> ... that the guest should see.
>> Guest operating systems may check the microcode version to decide whether
>> to disable certain features that are known to be buggy up to certain
>> microcode ver
On Sat, Dec 09, 2017 at 06:16:04AM +, alexander.le...@verizon.com wrote:
> On Fri, Dec 08, 2017 at 03:56:40AM +, Ben Hutchings wrote:
> >On Thu, 2017-12-07 at 14:07 +0100, Greg Kroah-Hartman wrote:
> >> 4.4-stable review patch. If anyone has any objections, please let me know.
> >>
> >> --
> On 27. Nov 2017, at 02:40, Paolo Bonzini wrote:
>
> On 26/11/2017 17:41, Filippo Sironi wrote:
>> ... that the guest should see.
>> Guest operating systems may check the microcode version to decide whether
>> to disable certain features that are known to be buggy up to certain
>> microcode ver
On Fri, Dec 08, 2017 at 03:42:10PM +, John Garry wrote:
> On 08/12/2017 12:29, Jiri Olsa wrote:
> > On Wed, Dec 06, 2017 at 03:20:14PM +, John Garry wrote:
> > > On 06/12/2017 13:36, Jiri Olsa wrote:
> > > > On Wed, Dec 06, 2017 at 12:13:16AM +0800, John Garry wrote:
> > > > > For some arch
Acked-by: Sudarsana Kalluru
-Original Message-
From: Arnd Bergmann [mailto:a...@arndb.de]
Sent: 04 December 2017 20:17
To: Gurumurthy, Anil ; Kalluru, Sudarsana
; James E.J. Bottomley ;
Martin K. Petersen
Cc: Arnd Bergmann ; Hannes Reinecke ; Kees Cook
; Benjamin Poirier ; Mody, Rase
ARM v8.4 extensions include support for new floating point
multiplication variant instructions to the AArch64 SIMD
instructions set. Let the userspace know about it via a
HWCAP bit and MRS emulation.
Cc: Suzuki K Poulose
Signed-off-by: Dongjiu Geng
---
My platform supports this feature, so I nee
On Fri, Dec 08, 2017 at 03:38:06PM +, John Garry wrote:
SNIP
> > >
> > > Hi jirka,
> > >
>
> Hi jirka,
>
> > > The linux kernel headers are not used for jevents tool. I would rather use
> > > them if possible...
> >
> > should be as easy as adding #include ;-)
> >
>
> Hi jirka,
>
>
If 'mtd_device_parse_register()' fails, we still return 0 which mean
success.
Return the error code instead, as done in all the other error handling
paths.
Signed-off-by: Christophe JAILLET
---
Compile tested-only
v2: call 'onenand_release()' to undo 'onenand_scan()'
---
drivers/mtd/onenand/sam
Convert all error handling code in 's3c_onenand_probe()' to
resource-managed alternatives in order to simplify code.
This fixes a resource leak if 'platform_get_resource()' fails at line 872.
The 'request_irq()' at line 971 was also un-balanced. It is now
resource-managed.
Signed-off-by: Christo
The first patch converts 's3c_onenand_probe()' to devm_ functions.
This fixes a leak in one path (line 872).
This also free_irq which was not handled at all. (I hope I'm correct :) )
The 2nd patch is about an un-handled error code which looks spurious.
Not sure if I'm right.
While compile-testin
> On 26. Nov 2017, at 17:02, Wanpeng Li wrote:
>
> 2017-11-27 0:41 GMT+08:00 Filippo Sironi :
>> ... that the guest should see.
>> Guest operating systems may check the microcode version to decide whether
>> to disable certain features that are known to be buggy up to certain
>> microcode versio
A semaphore is acquired before this check, so we must release it before
leaving.
Fixes: b7f0554a56f2 ("mm: fail get_vaddr_frames() for filesystem-dax mappings")
Signed-off-by: Christophe JAILLET
---
-- Untested --
The wording of the commit entry and log description could be improved
but I didn't
ARM v8.4 extensions include support for new floating point
multiplication variant instructions to the AArch64 SIMD
instructions set. Let the userspace know about it via a
HWCAP bit and MRS emulation.
Cc: Suzuki K Poulose
Signed-off-by: Dongjiu Geng
---
My platform supports this feature, so I nee
Yeeloong is a laptop with a MIPS Loongson 2F processor, AMD CS5536
chipset, and KB3310B controller.
This yeeloong_laptop module enables access to sensors, battery,
video camera switch, external video connector event, and some
additional buttons.
This driver was orginally from linux-loongson-commu
This patch just add pdev during boot to load the platform driver
Signed-off-by: Jiaxun Yang
---
arch/mips/loongson64/lemote-2f/Makefile | 2 +-
arch/mips/loongson64/lemote-2f/platform.c | 29 +
2 files changed, 30 insertions(+), 1 deletion(-)
create mode 100755 ar
To operate EC from platform driver, this head file need able to be include
from anywhere. This patch just move ec_kb3310b.h to include dir and
clean up ec_kb3310b.h.
Signed-off-by: Jiaxun Yang
---
arch/mips/include/asm/mach-loongson64/ec_kb3310b.h | 170 +++
arch/mips/loongson64/
Since lemote-2f/marchtype.c need to get cmdline from loongson.h
this patch simply copy kernel command line from arcs_cmdline
to fix that issue
Signed-off-by: Jiaxun Yang
---
arch/mips/include/asm/mach-loongson64/loongson.h | 6 ++
arch/mips/loongson64/common/cmdline.c| 7 +++
Add myself as a maintainer of Lemote YeeLoong Extra driver
Signed-off-by: Jiaxun Yang
---
MAINTAINERS | 6 ++
1 file changed, 6 insertions(+)
mode change 100644 => 100755 MAINTAINERS
diff --git a/MAINTAINERS b/MAINTAINERS
old mode 100644
new mode 100755
index 1c3feffb1c1c..f576db163986
---
Change since v3:
Fix build error in platform.c
In case function skl_format_to_drm returns -EINVAL, fmt turns into a huge
number as fmt is of type u32, hence there is an out-of-bounds read when
using fmt as an index for array skl_pixel_formats at line 225:
plane->bpp = skl_pixel_formats[fmt].bpp;
Fix this by comparing the value returned by func
[Adding Laura]
On Fri, Dec 08, 2017 at 06:18:45PM -0800, Joe Perches wrote:
> 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 t
Use 'seq_printf(m, "...%*phN...")' instead of duplicating its
implementation.
Signed-off-by: Christophe JAILLET
---
drivers/s390/block/dasd_eckd.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/s390/block/dasd_eckd.c b/drivers/s390/block/dasd_eckd.c
index a2ed
On Fri, Dec 08, 2017 at 03:56:40AM +, Ben Hutchings wrote:
>On Thu, 2017-12-07 at 14:07 +0100, Greg Kroah-Hartman wrote:
>> 4.4-stable review patch. If anyone has any objections, please let me know.
>>
>> --
>>
>> From: Ben Hutchings
>>
>>
>> [ Upstream commit c15562c0dcb2c7f2
On 12/08/17 05:13, Geert Uytterhoeven wrote:
> Hi Pantelis, Rob, Frank,
>
> This patch series fixes memory corruption when applying overlays.
>
> I first noticed this when using OF configfs. After lots of failed
> debugging attempts, I bisected it to "of: overlay: add per overlay sysfs
> a
the result of cgroup_file_name will be used by kernfs_remove_name,
and then by kernfs_remove_by_name_ns().
If reached the max length, may have problem printed by WARN() in
kernfs_remove_by_name_ns().
Signed-off-by: Ma Shimiao
---
kernel/cgroup/cgroup.c | 2 +-
1 file changed, 1 insertion(+), 1 d
On 12/8/2017 5:27 PM, Wanpeng Li wrote:
2017-12-08 16:28 GMT+08:00 Tianyu Lan :
Hi Jim&Wanpeng:
Thanks for your help.
2017-12-08 5:25 GMT+08:00 Jim Mattson :
Try disabling the module parameter, "unrestricted_guest." Make sure
that the module parameter, "emulate_invalid_guest_state"
On Thu, Dec 07, 2017 at 08:41:14PM +, Ben Hutchings wrote:
>On Tue, 2017-11-28 at 11:23 +0100, Greg Kroah-Hartman wrote:
>> 4.4-stable review patch. If anyone has any objections, please let me know.
>>
>> --
>>
>> From: Geert Uytterhoeven
>>
>>
>> [ Upstream commit dadab2d4e3c
On Thu, Dec 07, 2017 at 08:16:05PM +, Ben Hutchings wrote:
>On Tue, 2017-11-28 at 11:23 +0100, Greg Kroah-Hartman wrote:
>> 4.4-stable review patch. If anyone has any objections, please let me
>> know.
>>
>> --
>>
>> From: Daniel Vetter
>>
>>
>> [ Upstream commit 7357f89954b6d
On Thu, Dec 07, 2017 at 09:21:10PM +, Ben Hutchings wrote:
>On Tue, 2017-11-28 at 11:23 +0100, Greg Kroah-Hartman wrote:
>> 4.4-stable review patch. If anyone has any objections, please let me know.
>>
>> --
>>
>> From: Heiko Carstens
>>
>>
>> [ Upstream commit cabab3f9f5ca077
/linux/kernel/git/jmorris/linux-security.git
keys-for-linus
for you to fetch changes up to 4ded3bec65a07343258ed8fd9d46483f032d866f:
Merge tag 'keys-fixes-20171208' of
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs into
keys-for-linus (2017-12-09 14:3
Hi Mark,
On Dec 9 2017 03:52, Mark Brown wrote:
The patch
ASoC: rsnd: ssi: fix race condition in rsnd_ssi_pointer_update
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
The applied patches are in v1 patchset, but we have v2 patc
earlyprintk=efi,keep does not work any more with a warning
in mm/early_ioremap.c: WARN_ON(system_state != SYSTEM_BOOTING):
Boot just hangs because of the earlyprintk within earlyprintk
implementation code.
This is caused by a new introduced middle state in below commit:
commit 69a78ff226fe ("init:
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
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 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 /
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 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 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
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
--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?
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
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
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
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
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 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
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
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
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
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
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/
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
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
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 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
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(+)
>
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
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
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
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)
>>
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
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
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 -
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
>
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:
> 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:
> 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:
> 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:
> 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:
> 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:
> 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
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 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
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
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
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
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
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
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
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
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/
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
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: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
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 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 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
1 - 100 of 935 matches
Mail list logo
