On Fri 2014-09-05 12:17:16, Peter Hurley wrote:
> On 09/05/2014 08:37 AM, David Laight wrote:
> > From: Peter Hurley
> >> On 09/05/2014 04:30 AM, David Laight wrote:
> >>> I've seen gcc generate 32bit accesses for 16bit structure members on arm.
> >>> It does this because of the more limited range
Hi!
> +/**
> + * register_poweroff_handler_simple - Register function to be called to
> power off
> + * the system
> + * @handler: Function to be called to power off the system
> + * @priority: Handler priority. For priority guidelines see
> +
On Mon 2014-10-06 22:28:05, Guenter Roeck wrote:
> Poweroff handlers may now be installed with register_poweroff_handler.
> Use the new API function have_kernel_poweroff to determine if a poweroff
> handler has been installed.
>
> Cc: Rafael J. Wysocki
> Cc: Pavel Mache
Hi!
> @@ -184,6 +179,8 @@ machine_halt(void)
> void
> machine_power_off(void)
> {
> + do_kernel_poweroff();
> +
poweroff -> power_off for consistency.
> index c4f50a3..1da27d1 100644
> --- a/arch/blackfin/kernel/reboot.c
> +++ b/arch/blackfin/kernel/reboot.c
> @@ -106,6 +107,7 @@ void ma
Hi!
> >>@@ -184,6 +179,8 @@ machine_halt(void)
> >> void
> >> machine_power_off(void)
> >> {
> >>+ do_kernel_poweroff();
> >>+
> >
> >poweroff -> power_off for consistency.
> >
> Dunno; matter of personal preference. I started with that, but ultimately went
> with poweroff to distinguish powe
Hi!
> +const char *const counter_count_direction_str[2] = {
> + [COUNTER_COUNT_DIRECTION_FORWARD] = "forward",
> + [COUNTER_COUNT_DIRECTION_BACKWARD] = "backward"
> +};
> +EXPORT_SYMBOL_GPL(counter_count_direction_str);
> +
> +const char *const counter_count_mode_str[4] = {
> + [COUNTE
On Tue 2019-04-02 15:30:37, William Breathitt Gray wrote:
> This patch adds standard documentation for the userspace sysfs
> attributes of the Generic Counter interface.
>
> Reviewed-by: Jonathan Cameron
> Signed-off-by: William Breathitt Gray
> ---
> Documentation/ABI/testing/sysfs-bus-counter
Hi!
> The 00-INDEX files are supposed to give a summary of all files present
> in a directory, but these files are horribly out of date and their
> usefulness is brought into question. Often a simple "ls" would reveal
> the same information as the filenames are generally quite descriptive as
> a s
On Wed 2009-09-02 07:33:31, Peter Zijlstra wrote:
> On Fri, 2009-08-28 at 15:30 +0530, Gautham R Shenoy wrote:
> > Hi,
> >
> > This is the version 2 of the patch series to provide a cpu-offline framework
> > that enables the administrators choose the state the offline CPU must be put
> > into when
On Tue 2009-09-15 14:11:41, Peter Zijlstra wrote:
> On Tue, 2009-09-15 at 17:36 +0530, Gautham R Shenoy wrote:
> > This patchset contains the offline state driver implemented for
> > pSeries. For pSeries, we define three available_hotplug_states. They are:
> >
> > online: The processor is
On Fri 2009-10-16 15:13:08, Arun R Bharadwaj wrote:
> * Arun R Bharadwaj [2009-10-16 15:08:50]:
>
> This patch cleans up x86 of all instances of pm_idle.
>
> pm_idle which was earlier called from cpu_idle() idle loop
> is replaced by cpuidle_idle_call.
>
> x86 also registers to cpuidle when the
> > > +static int local_idle_loop(struct cpuidle_device *dev, struct
> > > cpuidle_state *st)
> > > +{
> > > + ktime_t t1, t2;
> > > + s64 diff;
> > > + int ret;
> > > +
> > > + t1 = ktime_get();
> > > + local_idle();
> > > + t2 = ktime_get();
> > > +
> > > + diff = ktime_to_us(ktime_sub(t2, t1))
On Wed 2009-03-25 18:42:41, Li Yang wrote:
> On Tue, Mar 24, 2009 at 12:54 AM, Scott Wood wrote:
> > On Sun, Mar 22, 2009 at 10:45:23PM -0700, Li Yang-R58472 wrote:
> >> > I don't think so, in this case. The user is not asking for
> >> > "sleep" or deep sleep"; they are asking for a power state
>
On Wed 2009-03-25 11:31:57, Scott Wood wrote:
> Pavel Machek wrote:
>>> Pavel, what's the preferred way for current PM sub-system?
>>
>> If you have single sleep state, use "mem" > /sys/power/state.
>>
>> If you have two, use mem and standby.
...according to gcc docs, sp should be global, or placement in
register is not guaranteed (except at asm boundaries, but there are
none).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://at
> On Tue, 2010-02-09 at 16:24 +0100, Pavel Machek wrote:
> > ...according to gcc docs, sp should be global, or placement in
> > register is not guaranteed (except at asm boundaries, but there are
> > none).
>
> Sorry I'm not sure I grok what you mean.
Wel
On Tue 2010-02-16 06:59:52, Benjamin Herrenschmidt wrote:
> On Mon, 2010-02-15 at 08:34 +0100, Pavel Machek wrote:
> > > On Tue, 2010-02-09 at 16:24 +0100, Pavel Machek wrote:
> > > > ...according to gcc docs, sp should be global, or placement in
> > > > regis
On Mon 2010-02-15 14:15:17, H. Peter Anvin wrote:
> On 02/15/2010 01:04 PM, Benjamin Herrenschmidt wrote:
> >
> > It's true that most other use of it we have are global scope (local_paca
> > in r13, glibc use of r2/r13, etc...) afaik, but since r1 itself is the
> > stack pointer always, I think th
On Mon 2011-05-16 10:36:05, James Morris wrote:
> On Fri, 13 May 2011, Ingo Molnar wrote:
> How do you reason about the behavior of the system as a whole?
>
>
> > I argue that this is the LSM and audit subsystems designed right: in the
> > long
> > run it could allow everything that LSM does
> + for (action = enb->actions; action->name; action++) {
> + struct dentry *file = debugfs_create_int(action->name, mode,
> + enb->dir, &action->error);
> +
> + if (!file) {
> + debugfs_remove_recursive(en
On Thu 2009-05-07 12:11:29, Ingo Molnar wrote:
>
> * Nicholas Miell wrote:
>
> > On Wed, 2009-05-06 at 15:21 -0700, Markus Gutschke (?) wrote:
> > > On Wed, May 6, 2009 at 15:13, Ingo Molnar wrote:
> > > > doing a (per arch) bitmap of harmless syscalls and replacing the
> > > > mode1_sy
Hi!
> > > Also, approaches such as [1] can make use of this
> > > extended infrastructure instead of putting the CPU to an arbitrary C-state
> > > when it is offlined, thereby providing the system administrator a rope to
> > > hang
> > > himself with should he feel the need to do so.
> > I didn't
Hi!
> > Also, approaches such as [1] can make use of this
> > extended infrastructure instead of putting the CPU to an arbitrary C-state
> > when it is offlined, thereby providing the system administrator a rope to
> > hang
> > himself with should he feel the need to do so.
> I didn't see the rea
On Sun 2009-08-09 15:22:02, Rafael J. Wysocki wrote:
> On Sunday 09 August 2009, Pavel Machek wrote:
> > Hi!
> >
> > > > Also, approaches such as [1] can make use of this
> > > > extended infrastructure instead of putting the CPU to an arbitrary
>
Hi!
> May be having (to pick a number) 3 possible offline states for all
> platforms with one for halt equivalent and one for deepest possible that
> CPU can handle and one for deepest possible that platform likes for
> C-states may make sense. Will keeps things simpler in terms of usage
> expecta
> > > 2. A low-power state where the guest indicates it doesn't need the
> > > CPU (and can be put in low power state) but doesn't want to give up
> > > its allocated cpu share. IOW, no visible configuration changes.
> > >
> > > So, in any case we would probably want more than one states.
> >
>
Hi!
> > + /* Begin with first registered wakeup source */
> > + ws = wakeup_source_get_start(&idx);
>
> Since I have mad some change in this version, could you please take a look on
> this.
> If it's OK to you, I would re-add 'Acked-by: Pavel Mache
Hi!
> From: Marco Elver
>
> [ Upstream commit f95e5a3d59011eec1257d0e76de1e1f8969d426f ]
>
> Internal data structures (cpu_bps, task_bps) of powerpc's hw_breakpoint
> implementation have relied on nr_bp_mutex serializing access to them.
>
> Before overhauling synchronization of kernel/events/h
Hi!
> This adds platform_suspend_ops for PMU based machines, directly in
> the PMU driver. This finally allows suspending via /sys/power/state
> on powerbooks.
Thanks for doing this!
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/p
On Sat 2007-12-08 09:52:06, Balbir Singh wrote:
> David Rientjes wrote:
> > On Sat, 8 Dec 2007, Balbir Singh wrote:
> >
> >> To be able to test the memory controller under NUMA, I use fake NUMA
> >> nodes. x86-64 has a similar feature, the code I have here is the
> >> simplest I could come up wit
On Sun 2007-08-26 02:03:49, Guennadi Liakhovetski wrote:
> Implement suspend/resume for "mpc10x" compatible fsl host PCI controllers,
> use it for linkstation standby.
>
> Signed-off-by: Guennadi Liakhovetski <[EMAIL PROTECTED]>
Looks okay to me. I'm glad to see "standby" is present on non-i386
Hi!
> I didn't know who to include as the wizards of the matter.
>
> > > If I, on the other hand, use Debian's kernel 2.6.22 or compile my own
> > > kernel with just the necessary parts for my work (version 2.6.23-rc3
> > > taken from kernel.org), then I can't make the machine sleep: when I
> >
Hi!
> > Though it's my understanding that at least ia64 does require the
> > explicit barriers anyway, so we are still in a dodgy situation here
> > where it's not clear what drivers should do and we end up with
> > possibly excessive barriers on powerpc where I end up with both
> > the wmb/r
Hi!
> >>The only way to guarantee ordering in the above setup,
> >>is to either
> >>make writel() fully ordered or adding the mmiowb()'s
> >>inbetween the two
> >>writel's. On Altix you have to go and read from the
> >>PCI brige to
> >>ensure all writes to it have been flushed, which is
> >>al
On Thu 2008-11-20 17:05:56, Trent Piepho wrote:
> On Mon, 17 Nov 2008, Richard Purdie wrote:
> > On Fri, 2008-10-24 at 16:09 -0700, Trent Piepho wrote:
> >> + if (template->keep_state)
> >> + state = !!gpio_get_value(led_dat->gpio) ^ led_dat->active_low;
> >> + else
> >> + state
Hi!
> From: Minghao Chi
>
> Using pm_runtime_resume_and_get is more appropriate
> for simplifing code
>
> Reported-by: Zeal Robot
> Signed-off-by: Minghao Chi
> ---
> sound/soc/fsl/fsl_esai.c | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/sound/soc/fsl/fsl_es
On Sun 2021-05-02 00:15:38, Masahiro Yamada wrote:
> The current minimum GCC version is 4.9 except ARCH=arm64 requiring
> GCC 5.1.
Please don't. I'm still on 4.9 on machine I can't easily update,
> Documentation/process/changes.rst | 2 +-
> arch/arm64/Kconfig| 2 +-
> arch/power
On Tue 2020-07-07 11:04:05, Randy Dunlap wrote:
> Drop the doubled word "for".
>
> Signed-off-by: Randy Dunlap
> Cc: Jonathan Corbet
> Cc: linux-...@vger.kernel.org
> Cc: Jacek Anaszewski
Acked-by: Pavel Machek
(I expect documentation people take this,
Hi!
Something went wrong with this series. I only see first 7 patches. I
thought it might be local problem, but I only see 7 patches on lore...
https://lore.kernel.org/lkml/20210923033839.1421034-1-sas...@kernel.org/
Best regards,
P
Hi!
> +
> +struct rcpm {
> + unsigned int wakeup_cells;
> + void __iomem *ippdexpcr_base;
> + boollittle_endian;
> +};
Inconsistent whitespace
> +static int rcpm_pm_prepare(struct device *dev)
> +{
> + struct device_node *np = dev->of_node;
> + struct wakeup_source *ws;
> --- a/include/linux/pm_wakeup.h
> @@ -70,6 +71,7 @@ struct wakeup_source {
> unsigned long wakeup_count;
> boolactive:1;
> boolautosleep_enabled:1;
> + struct device *attached_dev;
> };
>
> #ifdef CONFIG_PM_SLEEP
You
Hi!
> The NXP's QorIQ Processors based on ARM Core have RCPM module
> (Run Control and Power Management), which performs all device-level
> tasks associated with power management such as wakeup source control.
>
> This driver depends on PM wakeup source framework which help to
> collect wake info
Hi!
> > > +static int rcpm_pm_prepare(struct device *dev) {
> > > + struct device_node *np = dev->of_node;
> > > + struct wakeup_source *ws;
> > > + struct rcpm *rcpm;
> > > + u32 value[RCPM_WAKEUP_CELL_MAX_SIZE + 1], tmp;
> > > + int i, ret;
> > > +
> > > + rcpm = dev_get_drvdata(dev);
> > > + if
On Mon 2019-05-20 09:03:50, Ran Wang wrote:
> Hi Pavel,
>
> On Monday, May 20, 2019 16:57, Pavel Machek wrote:
> >
> > Hi!
> >
> > > > > +static int rcpm_pm_prepare(struct device *dev) {
> > > > > + struct device_node *np
s confusing to the reader.
>
> OK, if no other comment, I will work out v4, fix this and extra ','
>
> > Thanks (and sorry for cross-talk),
>
> That's OK, thanks for your time.
You can add
Acked-by: Pavel Machek
to that version.
Best regards,
Fix overlapping NAND partitions.
Signed-off-by: Pavel Machek
diff --git a/arch/powerpc/boot/dts/sequoia.dts
b/arch/powerpc/boot/dts/sequoia.dts
index b1d3292..e41b88a 100644
--- a/arch/powerpc/boot/dts/sequoia.dts
+++ b/arch/powerpc/boot/dts/sequoia.dts
@@ -229,7 +229,7
On Sun 2017-04-02 12:05:36, Pavel Machek wrote:
> Fix overlapping NAND partitions.
>
> Signed-off-by: Pavel Machek
Ping? Two partitions at same place are bad news...
Pavel
> diff --git a/arch/powerpc/boot/dts
On Wed 2017-05-17 14:37:17, Andrew Morton wrote:
> On Wed, 17 May 2017 14:06:13 +0200 Pavel Machek wrote:
>
> > On Sun 2017-04-02 12:05:36, Pavel Machek wrote:
> > > Fix overlapping NAND partitions.
> > >
> > > Signed-off-by: Pavel Machek
> >
&
Hi!
> > Well... two partitions at same place. If you use one, you will corrupt
> > information on the other one.
> >
> > OTOH this moves partition around (so that they don't overlap) so it is
> > probably not stable candidate.
> >
> > I guess this is not huge issue; people using these boards proba
Hi!
> >>> > > Signed-off-by: Pavel Machek
> >>> >
> >>> > Ping? Two partitions at same place are bad news...
> >>>
> >>> Please expand on "bad news"? What are the runtime effects of this
> >>>
Hi!
> Memory protection keys enable applications to protect its
> address space from inadvertent access or corruption from
> itself.
>
> The overall idea:
>
> A process allocates a key and associates it with
> a address range withinits address space.
> The process than can dy
Hi!
> --- a/Documentation/ABI/testing/sysfs-kernel-livepatch
> +++ b/Documentation/ABI/testing/sysfs-kernel-livepatch
> @@ -33,6 +33,15 @@ Contact: live-patch...@vger.kernel.org
> An attribute which indicates whether the patch is currently in
> transition.
>
> +What
Fix double ;;'s in code.
Signed-off-by: Pavel Machek
diff --git a/arch/arc/kernel/setup.c b/arch/arc/kernel/setup.c
index 9d27331..ec12fe1 100644
--- a/arch/arc/kernel/setup.c
+++ b/arch/arc/kernel/setup.c
@@ -373,7 +373,7 @@ static void arc_chk_core_config(void)
{
struct cpuinf
On Mon 2018-02-19 16:41:35, Daniel Vetter wrote:
> On Sun, Feb 18, 2018 at 11:00:56AM +0100, Christophe LEROY wrote:
> >
> >
> > Le 17/02/2018 à 22:19, Pavel Machek a écrit :
> > >
> > > Fix double ;;'s in code.
> > >
> > > Signed-
Hi!
> > diff --git a/drivers/soc/imx/gpc.c b/drivers/soc/imx/gpc.c
> > index 53f7275..cfb42f5 100644
> > --- a/drivers/soc/imx/gpc.c
> > +++ b/drivers/soc/imx/gpc.c
> > @@ -348,7 +348,7 @@ static int imx_gpc_old_dt_init(struct device *dev,
> > struct regmap *regmap,
> > if (i == 1) {
Hi!
> On Nokia N900:/dev/input/event6 aka AV Jack support disappeared
> Status: quite new
> Reported: 2018-02-24
> https://marc.info/?l=linux-omap&m=151950886524308&w=2
> Cause: 14e3e295b2b9
> Linux-Regression-ID: 4b650f
This one is now solved in the mainline.
Hi!
> Current implementation doesn't randomize address returned by mmap.
> All the entropy ends with choosing mmap_base_addr at the process
> creation. After that mmap build very predictable layout of address
> space. It allows to bypass ASLR in many cases. This patch make
> randomization of addre
On Fri 2018-03-30 12:07:58, Ilya Smith wrote:
> Hi
>
> > On 30 Mar 2018, at 10:55, Pavel Machek wrote:
> >
> > Hi!
> >
> >> Current implementation doesn't randomize address returned by mmap.
> >> All the entropy ends with choosing mmap_ba
> Anyway, you know the drill: Are you aware of any other regressions?
> Then please let me know. And tell me if there is anything in the
> report that shouldn't be there.
>
> Ciao, Thorsten
>
> P.S.: Thanks to all those that Aaro Koskinen, Hans de Goede, Pavel
> Ma
t8ek8_of_table_device_table'
>
> Fixes: 9ae05fd1e791 ("[media] et8ek8: Export OF device ID as module
aliases")
> Signed-off-by: Arnd Bergmann
> Acked-by: Sakari Ailus
> Acked-by: Pavel Machek
Pavel
--
(
d-off-by: Markus Elfring
Acked-by: Pavel Machek
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Hi!
> Hello Sasha,
>
> Thank you for considering this patch for the stable tree 6.9, 6.8, 6.6, and
> 6.1.
>
> This patch does two things:
> 1. Fixes a potential memory corruption issue mentioned as the third point in
> the commit message
> 2. Enables the kernel to avoid unnecessary fadump re-reg
This
> way driver authors are not tempted to assume that passing an error to
> the upper layer is a good idea. All drivers are adapted accordingly.
> There is no intended change of behaviour, all callbacks were prepared to
> return 0 before.
>
> Signed-off-by: Uwe Kleine-König
63 matches
Mail list logo
