On Tue, Feb 09, 2016 at 04:41:04PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20160208:
tilepro, tilegx, mips defconfig build fails with the error:
../include/asm-generic/fixmap.h: In function '__set_fixmap_offset':
../include/asm-generic/fixmap.h:77:2: error:
On Mon, Feb 08, 2016 at 05:07:08PM -0800, Stephen Boyd wrote:
> On 12/23, Sudip Mukherjee wrote:
> > Add a helper function devm_add_action_or_reset() which will internally
> > call devm_add_action(). But if devm_add_action() fails then it will
> > execute the action mentioned and return the error
Vinod Koul writes:
> On Mon, Feb 08, 2016 at 03:18:51PM +0100, Robert Jarzmik wrote:
>> The current number of requestor lines is limited to 31. This was an
>> error of a previous commit, as this number is platform dependent, and is
>> actually :
>> - for pxa25x: 40 requestor lines
>> - for
On Mon, Feb 08, 2016 at 10:31:36AM -0500, Boris Ostrovsky wrote:
>
>
> On 02/06/2016 03:05 PM, Andy Lutomirski wrote:
> >
> >Anyway, this is all ridiculous. I propose that rather than trying to
> >clean up paravirt_enabled, you just delete it. Here are its users:
> >
> >static inline bool
Good Morning,
On 02/08/2016 06:19 PM, Maciej W. Rozycki wrote:
> On Mon, 8 Feb 2016, Daniel Wagner wrote:
>
>> The generic auxvec.h is used instead the arch specific version.
>> This happens when cross compiling the kernel.
>>
>> mips64-linux-gnu-gcc (GCC) 5.2.1 20151104 (Red Hat Cross 5.2.1-4)
On Mon, Feb 08, 2016 at 04:46:08PM +0100, Borislav Petkov wrote:
> On Mon, Feb 08, 2016 at 10:31:36AM -0500, Boris Ostrovsky wrote:
> > This range is reserved for hypervisors but the only hypervisor that uses it
> > is Xen PV (lguest doesn't run in 64-bit mode).
>
> Yeah, this is mentioned in
On Sat, Feb 06, 2016 at 12:05:32PM -0800, Andy Lutomirski wrote:
> On Sat, Feb 6, 2016 at 12:59 AM, Luis R. Rodriguez wrote:
> > On Fri, Feb 05, 2016 at 11:11:34PM -0800, Andy Lutomirski wrote:
> >> On Feb 5, 2016 8:30 PM, "Luis R. Rodriguez" wrote:
> >> >
> >> > paravirt_enabled conveys the
The following change:
788d441 ALSA: hda - Use component ops for i915 HDMI/DP audio jack handling
breaks audio over HDMI on my snd_hda_intel laptop. It is the first bad
commit.
This was merged for -rc1 and isn't fixed until now, so I got nervous.
There are
no errors in the log that stand out.
On Tue, Feb 09, 2016 at 08:19:51AM +0200, Jarkko Sakkinen wrote:
> On Mon, Feb 08, 2016 at 10:26:55PM -0700, Jason Gunthorpe wrote:
> > On Tue, Feb 09, 2016 at 05:30:30AM +0200, Jarkko Sakkinen wrote:
> > > If the initialization fails before tpm_chip_register(), put_device()
> > > will be not
On Mon, Feb 08, 2016 at 04:53:00PM +, Andrew Cooper wrote:
> On 08/02/16 16:45, Borislav Petkov wrote:
> > On Mon, Feb 08, 2016 at 04:38:40PM +, Andrew Cooper wrote:
> >> Does the early loader have extable support? If so, this is fairly easy
> >> to fix. If not, we have a problem.
> > It
On Mon, Feb 08, 2016 at 10:26:55PM -0700, Jason Gunthorpe wrote:
> On Tue, Feb 09, 2016 at 05:30:30AM +0200, Jarkko Sakkinen wrote:
> > If the initialization fails before tpm_chip_register(), put_device()
> > will be not called, which causes release callback not to be called.
> > This patch fixes
On Feb 8, 2016 3:17 PM, "Scotty Bauer" wrote:
>
>
>
> On 02/08/2016 02:50 PM, Andy Lutomirski wrote:
> > On Sun, Feb 7, 2016 at 12:10 AM, Scotty Bauer wrote:
> >>
> >>
> >> On 02/06/2016 11:35 PM, Mika Penttilä wrote:
> >>> Hi,
> >>>
> >>>
> >>> On 07.02.2016 01:39, Scott Bauer wrote:
>
On Tue, Feb 9, 2016 at 12:22 AM, Mark Brown wrote:
> On Mon, Feb 08, 2016 at 10:56:05PM +0800, Chen-Yu Tsai wrote:
>> On Mon, Feb 8, 2016 at 10:53 PM, Mark Brown wrote:
>> > On Sat, Feb 06, 2016 at 08:42:24PM +0800, Chen-Yu Tsai wrote:
>
>> >> Mark, may I assume you are OK with this DTS include
Hi all,
Changes since 20160208:
The ext4 tree lost its build failure.
The xfs tree gained a build failure so I used the version from
next-20160208.
The gpio tree lost its build failure.
The aio tree still had a build failure so I used the version from
next-20160111.
The akpm-current tree
From: "David A. Long"
Move duplicate and functionally equivalent code for accessing registers
and stack (CONFIG_HAVE_REGS_AND_STACK_ACCESS_API) from arch subdirs into
common kernel files.
I'm sending this out again (with updated distribution list) because v2
just never got pulled in, even
From: "David A. Long"
Several architectures have identical or functionally equivalent code
implementing parts of the HAVE_REGS_AND_STACK_ACCESS_API feature. Move
that code out of the architecture directories.
Signed-off-by: David A. Long
---
arch/arm/include/asm/ptrace.h | 6 ---
From: "David A. Long"
The pt_regs_offset structure is used for the HAVE_REGS_AND_STACK_ACCESS_API
feature and has identical definitions in four different arch ptrace.h
include files. It seems unlikely that definition would ever need to be
changed regardless of architecture so lets move it into
Hi Stephen,
[auto build test ERROR on ljones-mfd/for-mfd-next]
[also build test ERROR on v4.5-rc3]
[cannot apply to clk/clk-next next-20160208]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits
On Monday 08 February 2016 11:49 PM, Mark Brown wrote:
* PGP Signed by an unknown key
On Mon, Feb 08, 2016 at 10:26:20PM +0530, Laxman Dewangan wrote:
So fix need to go in the irq_domain_remove() to unamp before actually
destroying the irq domain?
That's one option, but you could also do
On Tue, Feb 09, 2016 at 05:30:30AM +0200, Jarkko Sakkinen wrote:
> If the initialization fails before tpm_chip_register(), put_device()
> will be not called, which causes release callback not to be called.
> This patch fixes the issue by adding put_device() to devres list of
> the parent device.
On 08-02-16, 20:14, Shilpasri G Bhat wrote:
> Create sysfs attributes to export throttle information in
> /sys/devices/system/cpu/cpuX/cpufreq/throttle_stats directory. The
> newly added sysfs files are as follows:
>
> 1)/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/turbo_stat
>
Hi,
On Tuesday 09 February 2016 02:37 AM, Suman Anna wrote:
> On 02/08/2016 05:12 AM, Kishon Vijay Abraham I wrote:
>> Add a new hwmod flag to indicate custom reset handling and use it
>> for devices that require custom reset handling (like dsp, ipu, iva).
>>
>> Tested PCIe on dra7-evm and
Hi Tony,
On Tuesday 09 February 2016 02:14 AM, Tony Lindgren wrote:
> Hi Kishon,
>
> * Kishon Vijay Abraham I [160208 03:13]:
>> Add a new hwmod flag to indicate custom reset handling and use it
>> for devices that require custom reset handling (like dsp, ipu, iva).
>>
>> Tested PCIe on
Hi Tony,
On Tuesday 09 February 2016 01:21 AM, Tony Lindgren wrote:
> Hi Kishon,
>
> * Tony Lindgren [151130 21:40]:
>> Hi,
>>
>> Here are two fixes for rmmod and PM. These can be merged separately after
>> the review from the MUSB related changes.
>
> Looks like these two fixes never got
OPP core can handle the regulators by itself, and but it needs to know
the name of the regulator to fetch. Add support for that.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq-dt.c | 46
1 file changed, 46 insertions(+)
diff --git
In few use cases (like: cpufreq), it is desired to get the maximum
voltage latency for changing OPPs. Add support for that.
Signed-off-by: Viresh Kumar
---
drivers/base/power/opp/core.c | 59 +++
include/linux/pm_opp.h| 6 +
2 files changed,
"clock-latency" is handled by OPP layer for all bindings and so there is
no need to make special calls for V1 bindings. Use
dev_pm_opp_get_max_clock_latency() for both the cases.
Signed-off-by: Viresh Kumar
Reviewed-by: Stephen Boyd
---
drivers/cpufreq/cpufreq-dt.c | 5 +
1 file changed, 1
On Thu, Feb 4, 2016 at 9:05 PM, Shannon Zhao wrote:
> From: Shannon Zhao
>
> Sometimes it needs to check if there is a node in FDT by full path.
I'm confused. Are you searching by full path or...
> Introduce this helper to get the specified name subnode if it exists.
name of sub node?
Either
V2 bindings have better support for clock-latency and voltage-tolerance
and doesn't need special care. To use callbacks, like
dev_pm_opp_get_max_{transition|volt}_latency(), irrespective of the
bindings, the core needs to know clock-latency/voltage-tolerance for the
earlier bindings.
This patch
The core already have a valid regulator set for the device opp and the
unsupported OPPs are already disabled by the core. There is no need to
repeat that in the user drivers, get rid of it.
Signed-off-by: Viresh Kumar
Reviewed-by: Stephen Boyd
---
drivers/cpufreq/cpufreq-dt.c | 2 --
1 file
In few use cases (like: cpufreq), it is desired to get the maximum
latency for changing OPPs. Add support for that.
Signed-off-by: Viresh Kumar
Reviewed-by: Stephen Boyd
---
drivers/base/power/opp/core.c | 17 +
include/linux/pm_opp.h| 6 ++
2 files changed, 23
OPP core has got almost everything now to manage device's OPP
transitions, the only thing left is device's clk. Get that as well.
Signed-off-by: Viresh Kumar
Reviewed-by: Stephen Boyd
---
drivers/base/power/opp/core.c | 15 +++
drivers/base/power/opp/opp.h | 3 +++
2 files
On 2016年02月06日 22:24, weiyj...@163.com wrote:
From: Wei Yongjun
In case of error, the function devm_ioremap_resource() 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
---
OPP layer has all the information now to calculate transition latency
(clock_latency + voltage_latency). Lets reuse the OPP layer helper
dev_pm_opp_get_max_transition_latency() instead of open coding the same
in cpufreq-dt driver.
Signed-off-by: Viresh Kumar
Reviewed-by: Stephen Boyd
---
OPP core supports frequency/voltage changes based on the target
frequency now, use that instead of open coding the same in cpufreq-dt
driver.
Signed-off-by: Viresh Kumar
Reviewed-by: Stephen Boyd
---
drivers/cpufreq/cpufreq-dt.c | 73 ++--
1 file
This adds a routine, dev_pm_opp_set_rate(), responsible for configuring
power-supply and clock source for an OPP.
The OPP is found by matching against the target_freq passed to the
routine. This shall replace similar code present in most of the OPP
users and help simplify them a lot.
We have the device structure available now, lets use it for better print
messages.
Signed-off-by: Viresh Kumar
Reviewed-by: Stephen Boyd
---
drivers/cpufreq/cpufreq-dt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq-dt.c
OPP layer manages it now and cpufreq-dt driver doesn't need it. But, we
still need to check for availability of resources for deferred probing.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq-dt.c | 112 +--
1 file changed, 45 insertions(+), 67
Its already done by core and we don't need to get it anymore. And so,
we don't need to get of node in cpufreq_init() anymore, move that to
find_supply_name() instead.
Signed-off-by: Viresh Kumar
Reviewed-by: Stephen Boyd
---
drivers/cpufreq/cpufreq-dt.c | 46
That's the real purpose of this field, i.e. to take special care of old
OPP V1 bindings. Lets name it accordingly, so that it can be used
elsewhere.
Signed-off-by: Viresh Kumar
Reviewed-by: Stephen Boyd
---
drivers/cpufreq/cpufreq-dt.c | 6 +++---
1 file changed, 3 insertions(+), 3
Disable any OPPs where the connected regulator isn't able to provide the
specified voltage.
Signed-off-by: Viresh Kumar
Reviewed-by: Stephen Boyd
---
drivers/base/power/opp/core.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/base/power/opp/core.c
This allows the OPP core to request/free the regulator resource,
attached to a device OPP. The regulator device is fetched using the name
provided by the driver, while calling: dev_pm_opp_set_regulator().
This will work for both OPP-v1 and v2 bindings.
This is a preliminary step for moving the
good afternoon
http://froslunda.se/mostly.php?science=qgswfb1z2m1h9wgq2
Balsa
Remove the ftrace module notifier in favor of directly calling
ftrace_module_enable() and ftrace_release_mod() in the module loader.
Hard-coding the function calls directly in the module loader removes
dependence on the module notifier call chain and provides better
visibility and control over
In load_module(), the going notifiers are called during error handling when
an error occurs after the coming notifiers have already been called.
However, a module's state is still MODULE_STATE_COMING when the going
notifiers are called in the error path. To be consistent, also set
mod->state to
Put all actions that are performed after module->state is set to
MODULE_STATE_COMING in complete_formation() into a separate function
prepare_coming_module(). This prepares for the removal of ftrace and
livepatch module coming notifiers and instead the corresponding work will
be done in
Remove the livepatch module notifier in favor of directly enabling and
disabling patches to modules in the module loader. Hard-coding the
function calls ensures that ftrace_module_enable() is run before
klp_module_coming() during module load, and that klp_module_going() is
run before
As explained here [1], livepatch modules are failing to initialize properly
because the ftrace coming module notifier (which calls
ftrace_module_enable()) runs *after* the livepatch module notifier (which
enables the patch(es)). Thus livepatch attempts to apply patches to
modules before
Hi Andrew,
Today's linux-next merge of the akpm tree got a conflict in:
arch/x86/platform/efi/efi.c
between commit:
1e82b9479070 ("x86/efi: Show actual ending addresses in efi_print_memmap")
from the tip tree and commit:
e0532ef9f825 ("x86/efi: print size and base in binary units in
On Tue, 9 Feb 2016, Al Viro wrote:
> On Mon, Feb 08, 2016 at 03:28:30PM -0500, Nicolas Pitre wrote:
> > +ifdef CONFIG_TRIM_UNUSED_EXPSYMS
> > +cmd_undef_syms = $(NM) $@ | sed -n 's/^ \+U \(.*\)/\1/p' | xargs echo
>
> Umm... sed -nre 's/^ +U //p', perhaps?
Yep, I like it better.
Although I
On Tue, 9 Feb 2016, Rusty Russell wrote:
> Nicolas Pitre writes:
> > The config option to enable it all.
> >
> > Signed-off-by: Nicolas Pitre
>
> Nice series! In case you need it, here's my Ack. Despite the overlap
> with modules, it's all build trickery, so best via Sam's tree.
>
>
On Sat, Feb 6, 2016 at 3:50 AM, Baoquan He wrote:
> Hi,
>
> Recently people using big box servers are also very interested in kaslr and
> want
> to have it to enhance security. So allowing kaslr be able to randomize above
> 4G
> makes much sense for different kinds of system. I would like to
Job at British Petroleum. Please attached your cv via our recruiter team email:
bp.recruit...@job4u.com
On 02-02-16, 11:41, Viresh Kumar wrote:
> diff --git a/drivers/cpufreq/cpufreq-dt.c b/drivers/cpufreq/cpufreq-dt.c
> +static const char *find_supply_name(struct device *dev)
> {
> + struct device_node *np;
> struct property *pp;
> int cpu = dev->id;
> + const char *name =
On Mon, Feb 08, 2016 at 03:28:30PM -0500, Nicolas Pitre wrote:
> +ifdef CONFIG_TRIM_UNUSED_EXPSYMS
> +cmd_undef_syms = $(NM) $@ | sed -n 's/^ \+U \(.*\)/\1/p' | xargs echo
Umm... sed -nre 's/^ +U //p', perhaps?
On Fri, Feb 5, 2016 at 10:04 PM, Nishanth Menon wrote:
> +
> + msgmgr: msgmgr@02a0 {
> + compatible = "ti,k2g-message-manager", "ti,message-manager";
> + #mbox-cells = <1>;
> + reg-names = "queue_proxy_region", "queue_state_debug_region";
> +
On 08-02-16, 14:55, Stephen Boyd wrote:
> On 02/02, Viresh Kumar wrote:
> > static int allocate_resources(int cpu, struct device **cdev,
> > struct regulator **creg, struct clk **cclk)
> > {
> > @@ -200,6 +225,7 @@ static int cpufreq_init(struct cpufreq_policy *policy)
On 02/08/2016 08:06 AM, Andy Shevchenko wrote:
On Sat, Feb 6, 2016 at 7:28 PM, Måns Rullgård wrote:
Not very surprising either. The number of people using Linux on avr32
is probably approximately zero, and if anyone is, they're likely still
running 2.6.32 or thereabouts.
Once I tried up
Hi Dinh,
Thanks for your report.
2016-02-09 11:35 GMT+09:00 Dinh Nguyen :
> Hi Stephen,
>
> It appears that commit 5146e0b05966 "clk: simplify __clk_init_parent()"
> that is currently in linux-next is causing the following kernel crash on
> SoCFGPA[1].
>
> I have bisected to this commit and
On Mon, Feb 08, 2016 at 07:08:09PM +0100, Karsten Malcher wrote:
> Hello,
>
> i am sorry, but is it possible that a kernel bug for a special chipset is
> alive since kernel 3.2?
>
On uncommon hardware, anything is possible. I don't actually know
if that hardware is "uncommon", only that I do
On 02/08/2016 03:53 PM, Ben Hutchings wrote:
This is the start of the stable review cycle for the 3.2.77 release.
There are 87 patches in this series, which will be posted as responses
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made
Nicolas Pitre writes:
> The config option to enable it all.
>
> Signed-off-by: Nicolas Pitre
Nice series! In case you need it, here's my Ack. Despite the overlap
with modules, it's all build trickery, so best via Sam's tree.
Acked-by: Rusty Russell
Thanks,
Rusty.
On 08-02-16, 14:52, Stephen Boyd wrote:
> Ok the sequence makes sense now that it's clearly explained.
Should I consider it as a Reviewed-by ?
--
viresh
On 08-02-16, 14:52, Stephen Boyd wrote:
> Ok the sequence makes sense now that it's clearly explained. I
> wonder if we should create and destroy OPP tables when a device
> is created and destroyed instead of triggering that from a
> driver. I suppose not creating the tables until they're used is
On 08-02-16, 23:57, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> It is silly to jump around "return 0", so don't do that.
>
> Signed-off-by: Rafael J. Wysocki
> ---
>
> On top of the bleeding-edge branch of linux-pm.git.
>
> Thanks,
> Rafael
>
> ---
>
On 08-02-16, 23:41, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> The skip_work field in struct policy_dbs_info technically is a
> counter, so give it a new name to reflect that.
>
> No functional changes.
>
> Signed-off-by: Rafael J. Wysocki
> ---
>
> On top of the bleeding-edge
We used to drop policy->rwsem just before calling __cpufreq_governor()
in some cases earlier and so it was possible that __cpufreq_governor()
runs concurrently via separate threads.
In order to guarantee valid state transitions for governors,
'governor_enabled' was required to be protected using
We have got five common sysfs tunables between ondemand and conservative
governors, move their callbacks to cpufreq_governor.c to get rid of
redundant code.
Because of minor differences in the implementation of the callbacks,
some more per-governor callbacks are introduced in order to not
Ondemand governor already updates sample_delay_ns immediately on updates
to sampling rate, but conservative isn't doing that.
It was left out earlier as the code has been really complex to get that
done easily. But now things are sorted out very well, and we can follow
the same for conservative
Hi Rafael,
These are rest of the patches that fix some more locking issues with
policy->rwsem and do some minor optimization/cleanups.
These were part of the 13 patch series which was sent earlier. The last
patch is new, and does what I suggested to one of your commits.
V3->V4:
- Reordered all
This isn't followed properly by all parts of the core code, some follow
it, whereas others don't.
Enforcing it will also enable us to remove cpufreq_governor_lock, that
is used today because we can't guarantee that __cpufreq_governor() isn't
executed in parallel.
We should also ensure that the
The offline routine was separated into two halves earlier by
'commit 1aee40ac9c86 ("cpufreq: Invoke __cpufreq_remove_dev_finish()
after releasing cpu_hotplug.lock");.
And the reasons cited were, race issues between accessing policy's sysfs
files and policy kobject's cleanup.
That race isn't
'delay' is updated properly in all paths of the routine od_dbs_timer(),
leaving just one. And can be 0 only in that case.
Move the update to 'delay' as an else part of the if block.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/cpufreq_ondemand.c | 9 -
1 file changed, 4
cpufreq core now guarantees that policy->rwsem wouldn't get dropped
while calling CPUFREQ_GOV_POLICY_EXIT governor event and will be kept
acquired until the complete sequence of governor state changes has
finished.
And so we can remove the state machine checks that were put in place
earlier.
On Tuesday 09 February 2016 01:27 AM, Tony Lindgren wrote:
* Keerthy [160208 01:19]:
OMAP5 has 3 thermal zones cpu, core and multimedia.
On the other hand DRA7 has 5 thermal zones cpu, gpu, core, dspeve
and iva. Currently cpu, core and multimedia are being added via dt
and the other 2 are
> -Original Message-
> From: Greg KH [mailto:gre...@linuxfoundation.org]
> Sent: Sunday, February 07, 2016 9:34 PM
> To: Lijun Pan
> Cc: a...@arndb.de; de...@driverdev.osuosl.org; linux-
> ker...@vger.kernel.org; bhamc...@freescale.com; lijun.pan2...@gmail.com;
>
htab_get_table_size() either retrieve the size of the hash page table (HPT)
from the device tree - if the HPT size is determined by firmware - or
uses a heuristic to determine a good size based on RAM size if the kernel
is responsible for allocating the HPT.
To support a PAPR extension allowing
At the moment the hpte_removebolted callback in ppc_md returns void and
will BUG_ON() if the hpte it's asked to remove doesn't exist in the first
place. This is awkward for the case of cleaning up a mapping which was
partially made before failing.
So, we add a return value to hpte_removebolted,
This makes a number of cleanups to handling of mapping failures during
memory hotplug on Power:
For errors creating the linear mapping for the hot-added region:
* This is now reported with EFAULT which is more appropriate than the
previous EINVAL (the failure is unlikely to be related to
The cleanups to the (guest side) memory hotplug paths came up in the
context of allowing hash page table resizing for PAPR guests.
However, they stand on their own and can improve reporting of several
error conditions that could already happen.
Please apply.
David Gibson (4):
powerpc/mm: Clean
The ondemand and conservative governors use the global-attr or freq-attr
structures to represent sysfs attributes corresponding to their tunables
(which of them is actually used depends on whether or not different
policy objects can use the same governor with different tunables at the
same time
On Mon, Feb 08, 2016 at 03:18:51PM +0100, Robert Jarzmik wrote:
> The current number of requestor lines is limited to 31. This was an
> error of a previous commit, as this number is platform dependent, and is
> actually :
> - for pxa25x: 40 requestor lines
> - for pxa27x: 74 requestor lines
> -
An instance of 'struct dbs_data' can support multiple 'struct
policy_dbs_info' instances. To traverse all policy_dbs supported by a
dbs_data, create a list of policy_dbs within dbs_data.
We can traverse this list now, instead of traversing the loop for all
online CPUs in update_sampling_rate(),
"The previous commit introduced a new set of macros for creating sysfs
attributes that represent governor tunables and the old macros used for
this purpose are not needed any more, so drop them."
[ Rafael: Written changelog ]
Signed-off-by: Viresh Kumar
Tested-by: Juri Lelli
Tested-by:
Earlier, when the struct freq-attr was used to represent governor
attributes, the standard cpufreq show/store sysfs attribute callbacks
were applied to the governor tunable attributes and they always acquire
the policy->rwsem lock before carrying out the operation. That could
have resulted in an
There are few more common tunables shared across ondemand and
conservative governors. Move them to 'struct dbs_data' to simplify code.
Signed-off-by: Viresh Kumar
Tested-by: Juri Lelli
Tested-by: Shilpasri G Bhat
---
drivers/cpufreq/cpufreq_conservative.c | 38 ++-
Some tunables are present in governor specific structures, whereas one
(min_sampling_rate) is present in global 'struct dbs_data'.
The macro for that is pretty much specific to sampling_rate_min for now.
Next patch would be moving few more tunables to the 'struct dbs_data',
then it would be
Hi Rafael,
As suggested, I have kept only what you suggested and fixed them based
on your review comments.
@Juri and Shilpa: I have also added your Tested-by's, please let me know
if you don't prefer to add them here.
V3->V4:
- Keep only relevant patches for lockdep, will send cleanups patches
Hi Stephen,
[auto build test ERROR on ljones-mfd/for-mfd-next]
[also build test ERROR on v4.5-rc3 next-20160208]
[cannot apply to clk/clk-next]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits
Currently, the only error that htab_remove_mapping() can report is -EINVAL,
if removal of bolted HPTEs isn't implemeted for this platform. We make
a few clean ups to the handling of this:
* EINVAL isn't really the right code - there's nothing wrong with the
function's arguments - use ENODEV
On Fri, Jan 22, 2016 at 07:06:52PM +0800, Caesar Wang wrote:
> From: Addy Ke
>
> Generic dma controller on Rockchips' platform cannot support
> DMAFLUSHP instruction which make dma to flush the req of non-aligned
> or non-multiple of what we need. That will cause an unrecoverable
> dma bus
On Fri, Jan 22, 2016 at 07:06:50PM +0800, Caesar Wang wrote:
> From: Shawn Lin
>
> This patch add max_burst to dma_get_slave_caps for clients
> to get the burst capability of slave dma controller.
Applied, thanks
--
~Vinod
On Fri, Jan 22, 2016 at 07:06:45PM +0800, Caesar Wang wrote:
> From: Shawn Lin
>
> This patch adds the "arm, pl330-broken-no-flushp" for arm-pl330.
Applied, thanks
--
~Vinod
On Fri, Jan 22, 2016 at 07:06:51PM +0800, Caesar Wang wrote:
> From: Shawn Lin
>
> This patch add max burst capability for dmaengine and
> limit burst capability to one for PL330_QUIRK_BROKEN_NO_FLUSHP
Applied, thanks
--
~Vinod
If the initialization fails before tpm_chip_register(), put_device()
will be not called, which causes release callback not to be called.
This patch fixes the issue by adding put_device() to devres list of
the parent device.
Fixes: 313d21eeab ("tpm: device class for tpm")
Signed-off-by: Jarkko
On Fri, Jan 22, 2016 at 07:06:44PM +0800, Caesar Wang wrote:
> From: Boojin Kim
>
> This patch adds to support burst mode for dev-to-mem and
> mem-to-dev transmit.
>
> Signed-off-by: Boojin Kim
> Signed-off-by: Addy Ke
> Signed-off-by: Shawn Lin
> cc: Heiko Stuebner
> cc: Doug Anderson
>
On Fri, Jan 22, 2016 at 07:06:46PM +0800, Caesar Wang wrote:
> From: Addy Ke
>
> This patch add "arm,pl330-broken-no-flushp" quirk to avoid execute
> DMAFLUSHP if Soc doesn't support it.
Applied, thanks
--
~Vinod
On 08-02-16, 22:36, Rafael J. Wysocki wrote:
> On Mon, Feb 8, 2016 at 12:39 PM, Viresh Kumar wrote:
> > + ret = kobject_init_and_add(_data->kobj, >kobj_type,
> > + get_governor_parent_kobj(policy),
> > + gov->kobj_name);
>
>
On Mon, Feb 08, 2016 at 11:21:57PM +0100, Heiko Stuebner wrote:
> Hi Vinod,
>
> Am Montag, 8. Februar 2016, 18:44:19 schrieb Vinod Koul:
> > On Mon, Feb 08, 2016 at 10:27:04AM +0100, Heiko Stuebner wrote:
> > > Am Montag, 8. Februar 2016, 08:41:34 schrieb Vinod Koul:
> > > > On Mon, Feb 01, 2016
>From 31edd352fb7c2a72913f1977fa1bf168109089ad Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu
Date: Tue, 9 Feb 2016 02:47:45 -0500
Subject: [PATCH] powerpc/perf/hv-gpci: Increase request buffer size
The GPCI hcall allows for a 4K buffer but we limit the buffer
to 1K. The problem with a 1K
1 - 100 of 2346 matches
Mail list logo
