On Fri, Jan 29, 2021 at 5:37 PM Rafael J. Wysocki wrote:
>
> On Fri, Jan 29, 2021 at 7:48 AM Calvin Johnson
> wrote:
> >
> > On Thu, Jan 28, 2021 at 02:27:00PM +0100, Rafael J. Wysocki wrote:
> > > On Thu, Jan 28, 2021 at 2:12 PM Calvin Johnson
> > > wrot
On Fri, Jan 29, 2021 at 7:48 AM Calvin Johnson
wrote:
>
> On Thu, Jan 28, 2021 at 02:27:00PM +0100, Rafael J. Wysocki wrote:
> > On Thu, Jan 28, 2021 at 2:12 PM Calvin Johnson
> > wrote:
> > >
> > > On Thu, Jan 28, 2021 at 01:00:40PM +0100, Rafael J. Wysocki
On Thu, Jan 28, 2021 at 2:12 PM Calvin Johnson
wrote:
>
> On Thu, Jan 28, 2021 at 01:00:40PM +0100, Rafael J. Wysocki wrote:
> > On Thu, Jan 28, 2021 at 12:27 PM Calvin Johnson
> > wrote:
> > >
> > > Hi Rafael,
> > >
> > > Thanks for the rev
On Thu, Jan 28, 2021 at 12:27 PM Calvin Johnson
wrote:
>
> Hi Rafael,
>
> Thanks for the review. I'll work on all the comments.
>
> On Fri, Jan 22, 2021 at 08:22:21PM +0100, Rafael J. Wysocki wrote:
> > On Fri, Jan 22, 2021 at 4:43 PM Calvin Johnson
> >
On Fri, Jan 22, 2021 at 4:43 PM Calvin Johnson
wrote:
>
> Introduce ACPI mechanism to get PHYs registered on a MDIO bus and
> provide them to be connected to MAC.
>
> Describe properties "phy-handle" and "phy-mode".
>
> Signed-off-by: Calvin Johnson
> ---
>
> Changes in v4:
> - More cleanup
This
On Fri, Jan 22, 2021 at 7:13 PM Rafael J. Wysocki wrote:
>
> On Fri, Jan 22, 2021 at 4:46 PM Calvin Johnson
> wrote:
> >
> > Using fwnode_get_id(), get the reg property value for DT node
> > or get the _ADR object value for ACPI node.
This is not accurate AFAICS, be
On Fri, Jan 22, 2021 at 7:11 PM Rafael J. Wysocki wrote:
>
> On Fri, Jan 22, 2021 at 6:12 PM Andy Shevchenko
> wrote:
> >
> > On Fri, Jan 22, 2021 at 05:40:41PM +0100, Rafael J. Wysocki wrote:
> > > On Fri, Jan 22, 2021 at 4:46 PM Calvin Johnson
> > > wro
On Fri, Jan 22, 2021 at 4:46 PM Calvin Johnson
wrote:
>
> Using fwnode_get_id(), get the reg property value for DT node
> or get the _ADR object value for ACPI node.
>
> Signed-off-by: Calvin Johnson
> ---
>
> Changes in v4:
> - Improve code structure to handle all cases
>
> Changes in v3:
> - Mo
On Fri, Jan 22, 2021 at 6:12 PM Andy Shevchenko
wrote:
>
> On Fri, Jan 22, 2021 at 05:40:41PM +0100, Rafael J. Wysocki wrote:
> > On Fri, Jan 22, 2021 at 4:46 PM Calvin Johnson
> > wrote:
> > >
> > > Using fwnode_get_id(), get the reg property value for DT nod
On Fri, Jan 22, 2021 at 4:46 PM Calvin Johnson
wrote:
>
> Using fwnode_get_id(), get the reg property value for DT node
> or get the _ADR object value for ACPI node.
So I'm not really sure if this is going to be generically useful.
First of all, the meaning of the _ADR return value is specific t
On Wed, Jan 20, 2021 at 9:01 PM Saravana Kannan wrote:
>
> On Wed, Jan 20, 2021 at 11:15 AM Rafael J. Wysocki wrote:
> >
> > On Wed, Jan 20, 2021 at 7:51 PM Andy Shevchenko
> > wrote:
> > >
> > > On Wed, Jan 20, 2021 at 8:18 PM Rafael J. Wysocki
>
On Tue, Jan 12, 2021 at 7:02 PM Andy Shevchenko
wrote:
>
> On Tue, Jan 12, 2021 at 09:30:31AM -0800, Saravana Kannan wrote:
> > On Tue, Jan 12, 2021 at 5:42 AM Calvin Johnson
> > wrote:
> > >
> > > Using fwnode_get_id(), get the reg property value for DT node
> > > or get the _ADR object value fo
On Wed, Jan 20, 2021 at 7:51 PM Andy Shevchenko
wrote:
>
> On Wed, Jan 20, 2021 at 8:18 PM Rafael J. Wysocki wrote:
> > On Tue, Jan 12, 2021 at 7:02 PM Andy Shevchenko
> > wrote:
> > > On Tue, Jan 12, 2021 at 09:30:31AM -0800, Saravana Kannan wrote:
> > &g
On Wed, Jan 20, 2021 at 7:44 PM Andy Shevchenko
wrote:
>
> On Wed, Jan 20, 2021 at 8:18 PM Rafael J. Wysocki wrote:
> > On Tue, Jan 12, 2021 at 4:47 PM Andy Shevchenko
> > wrote:
> > > On Tue, Jan 12, 2021 at 3:42 PM Calvin Johnson
> > > wrote:
>
&g
On Tue, Jan 12, 2021 at 4:47 PM Andy Shevchenko
wrote:
>
> On Tue, Jan 12, 2021 at 3:42 PM Calvin Johnson
> wrote:
> >
> > Using fwnode_get_id(), get the reg property value for DT node
> > or get the _ADR object value for ACPI node.
> >
> > Signed-off-by: Calvin Johnson
> > ---
> >
> > Changes i
On Mon, Nov 30, 2020 at 7:50 PM Laurent Pinchart
wrote:
>
> Hi Rafael,
>
> On Mon, Nov 30, 2020 at 06:55:57PM +0100, Rafael J. Wysocki wrote:
> > On Mon, Nov 30, 2020 at 6:35 PM Laurent Pinchart wrote:
> > > On Mon, Nov 30, 2020 at 05:37:52PM +0100, Rafael J. Wysocki wr
On Mon, Nov 30, 2020 at 6:35 PM Laurent Pinchart
wrote:
>
> On Mon, Nov 30, 2020 at 05:37:52PM +0100, Rafael J. Wysocki wrote:
> > On Fri, Nov 27, 2020 at 11:16 AM Geert Uytterhoeven wrote:
> > > On Tue, Nov 10, 2020 at 10:29 AM Zhang Qilong
> > > wrote:
> >
On Fri, Nov 27, 2020 at 11:16 AM Geert Uytterhoeven
wrote:
>
> Hi Zhang,
>
> On Tue, Nov 10, 2020 at 10:29 AM Zhang Qilong wrote:
> > In many case, we need to check return value of pm_runtime_get_sync, but
> > it brings a trouble to the usage counter processing. Many callers forget
> > to decreas
On Sat, Nov 28, 2020 at 11:17 PM Zhang Qilong wrote:
>
> In the pm_runtime_resume_and_get, pm_runtime_resume() is
> synchronous. Caller had to look into the implementation
> to verify that a change for pm_runtime_resume_and_get [0].
Well, "resume" is "sync" by definition.
> So we use pm_rauntime
On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
wrote:
>
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > wrote:
[cut]
> >
> > Maintainers routinely review 1-line trivial patches, not to mention
> > internal API changes, etc.
>
>
erence leak. It has been discussed a lot[0][1]. So we add a function
> to deal with the usage counter for better coding.
>
> [0]https://lkml.org/lkml/2020/6/14/88
> [1]https://patchwork.ozlabs.org/project/linux-tegra/list/?series=178139
> Signed-off-by: Zhang Qilong
Acked-by: Rafael
On Mon, Nov 9, 2020 at 5:15 PM zhangqilong wrote:
>
> Hi
>
> >
> > On Mon, Nov 9, 2020 at 4:50 PM zhangqilong
> > wrote:
> > >
> > > > operation to deal with usage counter
> > > >
> > > > On Mon, Nov 9, 2020 at 4:00 PM Zhang Qilong
> > > >
> > > > wrote:
> > > > >
> > > > > In many case, we need
On Mon, Nov 9, 2020 at 4:50 PM zhangqilong wrote:
>
> > operation to deal with usage counter
> >
> > On Mon, Nov 9, 2020 at 4:00 PM Zhang Qilong
> > wrote:
> > >
> > > In many case, we need to check return value of pm_runtime_get_sync,
> > > but it brings a trouble to the usage counter processing
On Mon, Nov 9, 2020 at 4:50 PM Ulf Hansson wrote:
>
> On Mon, 9 Nov 2020 at 16:20, Rafael J. Wysocki wrote:
> >
> > On Mon, Nov 9, 2020 at 4:00 PM Zhang Qilong wrote:
> > >
> > > In many case, we need to check return value of pm_runtime_get_sync, but
&g
On Mon, Nov 9, 2020 at 4:00 PM Zhang Qilong wrote:
>
> In many case, we need to check return value of pm_runtime_get_sync, but
> it brings a trouble to the usage counter processing. Many callers forget
> to decrease the usage counter when it failed. It has been discussed a
> lot[0][1]. So we add a
On Mon, Nov 9, 2020 at 2:46 PM zhangqilong wrote:
>
> Hi,
>
> >
> > On Mon, Nov 9, 2020 at 2:24 PM zhangqilong
> > wrote:
> > >
> > > Hi
> > > >
> > > > On Mon, Nov 9, 2020 at 9:05 AM Zhang Qilong
> > > >
> > > > wrote:
> > > > >
> > > > > In many case, we need to check return value of
> > > > >
On Mon, Nov 9, 2020 at 9:05 AM Zhang Qilong wrote:
>
> In many case, we need to check return value of pm_runtime_get_sync, but
> it brings a trouble to the usage counter processing. Many callers forget
> to decrease the usage counter when it failed. It has been discussed a
> lot[0][1]. So we add a
On Mon, Nov 9, 2020 at 2:24 PM zhangqilong wrote:
>
> Hi
> >
> > On Mon, Nov 9, 2020 at 9:05 AM Zhang Qilong
> > wrote:
> > >
> > > In many case, we need to check return value of pm_runtime_get_sync,
> > > but it brings a trouble to the usage counter processing. Many callers
> > > forget to decre
On Fri, Oct 2, 2020 at 1:09 PM Grant Likely wrote:
>
>
>
> On 30/09/2020 17:37, Rafael J. Wysocki wrote:
> > On Wed, Sep 30, 2020 at 6:05 PM Calvin Johnson
> > wrote:
> >>
> >> Introduce ACPI mechanism to get PHYs registered on a MDIO bus an
On Wed, Sep 30, 2020 at 6:05 PM Calvin Johnson
wrote:
>
> Introduce ACPI mechanism to get PHYs registered on a MDIO bus and
> provide them to be connected to MAC.
>
> Describe properties "phy-handle" and "phy-mode".
>
> Signed-off-by: Calvin Johnson
> ---
>
> Documentation/firmware-guide/acpi/ds
On Fri, Aug 28, 2020 at 8:26 PM Anchal Agarwal wrote:
>
> On Fri, Aug 21, 2020 at 10:22:43PM +, Anchal Agarwal wrote:
> > Hello,
> > This series fixes PM hibernation for hvm guests running on xen hypervisor.
> > The running guest could now be hibernated and resumed successfully at a
> > later
On Fri, Jul 31, 2020 at 4:14 PM Boris Ostrovsky
wrote:
>
> On 7/30/20 7:06 PM, Anchal Agarwal wrote:
> > On Mon, Jul 27, 2020 at 06:08:29PM -0400, Boris Ostrovsky wrote:
> >> CAUTION: This email originated from outside of the organization. Do not
> >> click links or open attachments unless you ca
Hi Andrew,
On Tue, Jul 28, 2020 at 10:34 PM Andrew Lunn wrote:
>
> Hi Everybody
>
> So i think it is time to try to bring this discussion to some sort of
> conclusion.
>
> No ACPI maintainer is willing to ACK any of these patches. Nor are
> they willing to NACK them.
Let's first clarify one thin
On Wed, Jun 3, 2020 at 10:22 PM Abhishek Pandit-Subedi
wrote:
>
> It is preferable to allow suspend even when Bluetooth has problems
> preparing for sleep. When Bluetooth fails to finish preparing for
> suspend, log the error and allow the suspend notifier to continue
> instead.
>
> To also make i
On Tue, May 26, 2020 at 5:28 PM Alan Stern wrote:
>
> On Tue, May 26, 2020 at 05:19:07PM +0200, Rafael J. Wysocki wrote:
> > On Tue, May 26, 2020 at 5:07 PM Krzysztof Wilczyński wrote:
> > >
> > > Hello Greg,
> > >
> > > [...]
> > > > I
On Tue, May 26, 2020 at 5:07 PM Krzysztof Wilczyński wrote:
>
> Hello Greg,
>
> [...]
> > It's "interesting" how using your new helper doesn't actually make the
> > code smaller. Perhaps it isn't a good helper function?
>
> The idea for the helper was inspired by the comment Dan made to Bjorn
> a
On Tue, May 26, 2020 at 11:45 AM Pavel Machek wrote:
>
> On Tue 2020-05-26 10:37:36, Rafael J. Wysocki wrote:
> > On Mon, May 25, 2020 at 8:26 PM Krzysztof Wilczyński wrote:
> > >
> > > Use the new device_to_pm() helper to access Power Management callbacs
&
On Mon, May 25, 2020 at 8:26 PM Krzysztof Wilczyński wrote:
>
> Use the new device_to_pm() helper to access Power Management callbacs
> (struct dev_pm_ops) for a particular device (struct device_driver).
>
> No functional change intended.
>
> Signed-off-by: Krzysztof Wilczyński
> ---
> drivers/u
On Mon, May 25, 2020 at 8:26 PM Krzysztof Wilczyński wrote:
>
> Use the new device_to_pm() helper to access Power Management callbacs
> (struct dev_pm_ops) for a particular device (struct device_driver).
>
> No functional change intended.
>
> Signed-off-by: Krzysztof Wilczyński
> ---
> drivers/a
On Mon, May 25, 2020 at 8:26 PM Krzysztof Wilczyński wrote:
>
> Use the new device_to_pm() helper to access Power Management callbacs
> (struct dev_pm_ops) for a particular device (struct device_driver).
>
> No functional change intended.
>
> This change builds on top of the previous commit 6da2f2
On Wed, Apr 29, 2020 at 7:38 AM Calvin Johnson
wrote:
>
> On Mon, Apr 27, 2020 at 03:48:07PM +0100, Russell King - ARM Linux admin
> wrote:
> > On Mon, Apr 27, 2020 at 08:02:38PM +0530, Calvin Johnson wrote:
> > > On Mon, Apr 27, 2020 at 02:58:20PM +0100, Russell King - ARM Linux admin
> > > wro
On Mon, Jul 15, 2019 at 4:43 PM Joel Fernandes (Google)
wrote:
>
> list_for_each_entry_rcu has built-in RCU and lock checking. Make use of
> it for acpi_ioremaps list traversal.
>
> Signed-off-by: Joel Fernandes (Google)
Acked-by: Rafael J. Wysocki
> ---
> drivers/acpi/
On Thu, Feb 28, 2019 at 3:29 AM Brian Norris wrote:
>
> Hi Rafael,
>
> On Wed, Feb 27, 2019 at 3:04 PM Rafael J. Wysocki wrote:
> > On Wed, Feb 27, 2019 at 9:58 PM Brian Norris
> > wrote:
> > > On Wed, Feb 27, 2019 at 11:16:12AM +0100, Ard Biesheuvel wrote:
&g
On Wed, Feb 27, 2019 at 9:58 PM Brian Norris wrote:
>
> Hi Ard,
>
> On Wed, Feb 27, 2019 at 11:16:12AM +0100, Ard Biesheuvel wrote:
> > On Wed, 27 Feb 2019 at 11:02, Marc Zyngier wrote:
> > > On 26/02/2019 23:28, Brian Norris wrote:
> > > > You're not the first person to notice this. All the moti
On Thursday, February 21, 2019 6:49:40 AM CET Joel Fernandes (Google) wrote:
> Recently I added an RCU annotation check to rcu_assign_pointer(). All
> pointers assigned to RCU protected data are to be annotated with __rcu
> inorder to be able to use rcu_assign_pointer() similar to checks in
> other
On Thursday, November 8, 2018 8:55:47 AM CET Wang, Dongsheng wrote:
> On 2018/11/8 15:44, Rafael J. Wysocki wrote:
> > On Thursday, November 8, 2018 8:22:16 AM CET Wang Dongsheng wrote:
> >> Add support for parsing the ACPI data node for PHY devices on an MDIO bus.
> >>
On Thursday, November 8, 2018 8:22:16 AM CET Wang Dongsheng wrote:
> Add support for parsing the ACPI data node for PHY devices on an MDIO bus.
> The current implementation depend on mdio bus scan.
> With _DSD device properties we can finally do this:
>
> Device (MDIO) {
> Name (_DSD,
On Tue, Jul 24, 2018 at 6:49 PM, Kees Cook wrote:
> In the quest to remove all stack VLA usage from the kernel[1], this
> removes the discouraged use of AHASH_REQUEST_ON_STACK by switching to
> shash directly and allocating the descriptor in heap memory (which should
> be fine: the tfm has already
It is OK AFAICS.
Reviewed-by: Rafael J. Wysocki
On Tue, Jan 23, 2018 at 7:12 AM, Marcin Wojtas wrote:
> Hi Rafael,
>
>> > if (res)
>> > return res;
>> >
>> > - return device_get_mac_addr(dev, "address", addr, alen);
>> > + return fwnode_get_mac_addr(fwnode, "address", addr, alen);
>> > +}
>> > +EXPORT_SYMBOL(
o introduces a macro, thanks to which it is
> possible to iterate over the available fwnodes, using the
> new function described above.
>
> Signed-off-by: Marcin Wojtas
Acked-by: Rafael J. Wysocki
> ---
> drivers/base/property.c | 26
> include/linux/pro
dress(). This commit also changes
> device_get_mac_address() routine to be its wrapper, in order
> to prevent unnecessary duplication.
>
> Signed-off-by: Marcin Wojtas
> Acked-by: Rafael J. Wysocki
> ---
> drivers/base/property.c | 28 ++--
> include/linux/property.h
On Thu, Jan 18, 2018 at 1:31 PM, Marcin Wojtas wrote:
> Until now there were two very similar functions allowing
> to get Linux IRQ number from ACPI handle (acpi_irq_get())
> and OF node (of_irq_get()). The first one appeared to be used
> only as a subroutine of platform_irq_get(), which (in the g
_mode(). This commit also changes
> device_get_phy_mode() routine to be its wrapper, in order
> to prevent unnecessary duplication.
>
> Signed-off-by: Marcin Wojtas
Acked-by: Rafael J. Wysocki
> ---
> drivers/base/property.c | 24
> include/linux/pro
On Wednesday, January 3, 2018 11:38:12 AM CET Jonathan McDowell wrote:
> On Wed, Jan 03, 2018 at 11:11:29AM +0900, Joonsoo Kim wrote:
> > On Tue, Jan 02, 2018 at 11:25:01AM +0100, Rafael J. Wysocki wrote:
> > > On Tue, Jan 2, 2018 at 3:54 AM, Joonsoo Kim
> > > wrote:
&
dress(). This commit also changes
> device_get_mac_address() routine to be its wrapper, in order
> to prevent unnecessary duplication.
>
> Signed-off-by: Marcin Wojtas
The changes look reasonable to me, so
Acked-by: Rafael J. Wysocki
> ---
> drivers/base/property.c | 28 ++
On Tue, Jan 2, 2018 at 3:54 AM, Joonsoo Kim wrote:
> On Fri, Dec 29, 2017 at 04:36:59PM +, Jonathan McDowell wrote:
>> On Fri, Dec 22, 2017 at 09:21:09AM +0900, Joonsoo Kim wrote:
>> > On Fri, Dec 08, 2017 at 03:11:59PM +, Jonathan McDowell wrote:
>> > > I've been sitting on this for a whi
On Tuesday, December 26, 2017 3:36:41 AM CET Jeffy Chen wrote:
>
> Currently we are handling wake irq in mrvl wifi driver. Move it into
> pci core.
>
> Tested on my chromebook bob(with cros 4.4 kernel and mrvl wifi).
>
>
> Changes in v13:
> Fix compiler error reported by kbuild test robot
>
>
>
> const struct raid6_calls raid6_sse2x2 = {
> raid6_sse22_gen_syndrome,
> @@ -366,9 +366,9 @@ static void raid6_sse24_gen_syndrome(int disks, size_t
> bytes, void **ptrs)
> kernel_fpu_end();
> }
>
> - static void raid6_sse24_xor_syndrome(int disks, int start, int stop,
> +static void raid6_sse24_xor_syndrome(int disks, int start, int stop,
>size_t bytes, void **ptrs)
> - {
> +{
> u8 **dptr = (u8 **)ptrs;
> u8 *p, *q;
> int d, z, z0;
> @@ -471,7 +471,7 @@ static void raid6_sse24_gen_syndrome(int disks, size_t
> bytes, void **ptrs)
> }
> asm volatile("sfence" : : : "memory");
> kernel_fpu_end();
> - }
> +}
>
>
> const struct raid6_calls raid6_sse2x4 = {
> diff --git a/sound/soc/fsl/fsl_dma.c b/sound/soc/fsl/fsl_dma.c
> index 0c11f434a374..ec619f51d336 100644
> --- a/sound/soc/fsl/fsl_dma.c
> +++ b/sound/soc/fsl/fsl_dma.c
> @@ -879,7 +879,7 @@ static const struct snd_pcm_ops fsl_dma_ops = {
> };
>
> static int fsl_soc_dma_probe(struct platform_device *pdev)
> - {
> +{
> struct dma_object *dma;
> struct device_node *np = pdev->dev.of_node;
> struct device_node *ssi_np;
>
> --
Acked-by: Rafael J. Wysocki
for the ACPI part.
Thanks!
On 12/18/2017 10:17 AM, Marcin Wojtas wrote:
Hi,
This patchset introduces ACPI support in mvpp2 and mvmdio drivers.
First three patches introduce fwnode helpers for obtaining PHY
information from nodes and also MDIO fwnode API for registering
the bus with its PHY/devices.
Following patches upda
On Friday, October 27, 2017 9:26:05 AM CEST Jeffy Chen wrote:
>
> Currently we are handling wake irq in mrvl wifi driver. Move it into
> pci core.
>
> Tested on my chromebook bob(with cros 4.4 kernel and mrvl wifi).
>
>
> Changes in v10:
> Use device_set_wakeup_capable() instead of device_set_w
;
>
> -static struct config_item_type acpi_root_group_type = {
> +static const struct config_item_type acpi_root_group_type = {
> .ct_owner = THIS_MODULE,
> };
>
>
Acked-by: Rafael J. Wysocki
On Thu, Oct 5, 2017 at 10:57 AM, Daniel Drake wrote:
> Hi,
>
> On the Acer laptop models Aspire ES1-533, Aspire ES1-732, PackardBell
> ENTE69AP and Gateway NE533, we are seeing a problem where the system
> immediately wakes up after being put into S3 suspend.
>
> This problem has been seen on all
On Friday, September 1, 2017 1:29:43 AM CEST Kees Cook wrote:
> In several places, .data is checked for initialization to gate early
> calls to del_timer_sync(). Checking for .function is equally valid, so
> switch to this in all callers.
>
> Cc: "Rafael J. Wysocki"
>
On Monday, August 21, 2017 1:43:07 PM CEST Bhumika Goyal wrote:
> Make these const as they are only passed as an argument to the function
> device_create_file and device_remove_file and the corresponding
> arguments are of type const.
> Done using Coccinelle
>
> Signed-off-by: Bhumika Goyal
> ---
On Mon, Aug 21, 2017 at 1:43 PM, Bhumika Goyal wrote:
> Make these const. Done using Coccinelle.
>
> @match disable optional_qualifier@
> identifier s;
> @@
> static struct device_attribute s = {...};
>
> @ref@
> position p;
> identifier match.s;
> @@
> s@p
>
> @good1@
> identifier match.s;
> expr
On Fri, Feb 17, 2017 at 8:11 AM, Joe Perches wrote:
> There are ~4300 uses of pr_warn and ~250 uses of the older
> pr_warning in the kernel source tree.
>
> Make the use of pr_warn consistent across all kernel files.
>
> This excludes all files in tools/ as there is a separate
> define pr_warning
On Thursday, October 27, 2016 01:53:03 PM Ulf Hansson wrote:
> On 27 October 2016 at 13:41, Geert Uytterhoeven wrote:
> > Hi Ulf,
> >
> > On Thu, Oct 27, 2016 at 1:23 PM, Ulf Hansson wrote:
> >> The smsc911c driver puts its device into low power state when entering
> >> system suspend. Although i
On Friday, June 03, 2016 10:55:08 AM Yisen Zhuang wrote:
> From: Kejian Yan
>
> This series adds HNS support of acpi. The routine will call some ACPI
> helper functions, like acpi_dev_found() and acpi_evaluate_dsm(), which
> are not included in other cases. In order to make system compile
> succe
/acpi/processor_idle.c
> @@ -61,8 +61,8 @@ module_param(latency_factor, uint, 0644);
>
> static DEFINE_PER_CPU(struct cpuidle_device *, acpi_cpuidle_device);
>
> -static DEFINE_PER_CPU(struct acpi_processor_cx * [CPUIDLE_STATE_MAX],
> - acpi_cstate);
> +static
> +DEFINE_PER_CPU(struct acpi_processor_cx * [CPUIDLE_STATE_MAX], acpi_cstate);
>
> static int disabled_by_idle_boot_param(void)
> {
For the above:
Acked-by: Rafael J. Wysocki
On Monday, November 09, 2015 08:56:10 PM Tetsuo Handa wrote:
> There are many locations that do
>
> if (memory_was_allocated_by_vmalloc)
> vfree(ptr);
> else
> kfree(ptr);
>
> but kvfree() can handle both kmalloc()ed memory and vmalloc()ed memory
> using is_vmalloc_addr(). Unless call
On 10/6/2015 1:08 PM, David Woodhouse wrote:
On Mon, 2015-10-05 at 17:20 -0700, Charles Garcia-Tobin wrote:
it in ACPI circles
unless we had wider agreement among OSs to use it. AFAIK PRP1 has not
actually been approved yet in the specification forum, and that it in
itself is more of a conce
On Monday, September 28, 2015 10:24:58 AM Arnd Bergmann wrote:
> On Sunday 27 September 2015 16:10:48 Rafael J. Wysocki wrote:
> > On Saturday, September 26, 2015 09:33:56 PM Arnd Bergmann wrote:
> > > On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> > > >
needs to be robust for such a case.
>
> Fix that by changing type of 'global_lock' to u32.
>
> Signed-off-by: Viresh Kumar
Acked-by: Rafael J. Wysocki
Greg, please take this one along with the [2/2] if that one looks good to you.
> ---
> BCC'd a lot of people (
On Saturday, September 26, 2015 09:33:56 PM Arnd Bergmann wrote:
> On Saturday 26 September 2015 11:40:00 Viresh Kumar wrote:
> > On 25 September 2015 at 15:19, Rafael J. Wysocki wrote:
> > > So if you allow something like debugfs to update your structure, how
> > > do
On Saturday, September 26, 2015 12:52:08 PM James Bottomley wrote:
> On Fri, 2015-09-25 at 22:58 +0200, Rafael J. Wysocki wrote:
> > On Friday, September 25, 2015 01:25:49 PM Viresh Kumar wrote:
> > > On 25 September 2015 at 13:33, Rafael J. Wysocki
> > > wrote:
>
On 9/25/2015 5:28 PM, Catalin Marinas wrote:
On Thu, Sep 24, 2015 at 07:10:38PM +0100, David Woodhouse wrote:
On Thu, 2015-09-24 at 16:15 +0100, Catalin Marinas wrote:
With "PRP0001", they can skip the _DSD properties review process (not
that they bother much currently) as long as the existing
On Fri, Sep 25, 2015 at 11:44 PM, Viresh Kumar wrote:
> On 25-09-15, 22:58, Rafael J. Wysocki wrote:
>> Say you have three adjacent fields in a structure, x, y, z, each one byte
>> long.
>> Initially, all of them are equal to 0.
>>
>> CPU A writes 1 to x and CPU
On Friday, September 25, 2015 01:25:49 PM Viresh Kumar wrote:
> On 25 September 2015 at 13:33, Rafael J. Wysocki wrote:
> > You're going to change that into bool in the next patch, right?
>
> Yeah.
>
> > So what if bool is a byte and the field is not word-aligned
&
On Friday, September 25, 2015 10:26:22 PM Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 11:52:56 AM Viresh Kumar wrote:
> > On 25-09-15, 20:49, Johannes Berg wrote:
> > > Ok, then, but that means Rafael is completely wrong ...
> > > debugfs_create_bool() tak
On Friday, September 25, 2015 11:52:56 AM Viresh Kumar wrote:
> On 25-09-15, 20:49, Johannes Berg wrote:
> > Ok, then, but that means Rafael is completely wrong ...
> > debugfs_create_bool() takes a *pointer* and it needs to be long-lived,
> > it can't be on the stack. You also don't get a call whe
On Friday, September 25, 2015 10:18:13 PM Rafael J. Wysocki wrote:
> On Friday, September 25, 2015 09:41:37 AM Viresh Kumar wrote:
> > global_lock is defined as an unsigned long and accessing only its lower
> > 32 bits from sysfs is incorrect, as we need to consider other 32 b
ode needs to be robust for such a case.
>
> Fix that by passing a local variable to debugfs_create_bool() and
> assigning its value to global_lock later.
>
> Signed-off-by: Viresh Kumar
Acked-by: Rafael J. Wysocki
Greg, please take this one if the [2/2] looks good to you.
&
On 9/23/2015 8:41 PM, David Woodhouse wrote:
On Wed, 2015-08-12 at 17:06 -0500, Jeremy Linton wrote:
+static const struct acpi_device_id smsc911x_acpi_match[] = {
+ { "ARMH9118", 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, smsc911x_acpi_match);
+
static struct platform_driver smsc
On Wednesday, August 26, 2015 04:25:59 PM Guenter Roeck wrote:
> On 08/26/2015 04:37 PM, Rafael J. Wysocki wrote:
> > On Wednesday, August 26, 2015 01:20:44 PM Guenter Roeck wrote:
> >> Return -ENXIO if device property array access functions don't find
> >&g
On Wednesday, August 26, 2015 01:20:44 PM Guenter Roeck wrote:
> Return -ENXIO if device property array access functions don't find
> a suitable firmware interface.
>
> This lets drivers decide if they should use available platform data
> instead.
>
> Cc: Rafael J
Hi David,
On Fri, Aug 7, 2015 at 8:14 PM, David Daney wrote:
> On 08/07/2015 07:54 AM, Graeme Gregory wrote:
>>
>> On Thu, Aug 06, 2015 at 05:33:10PM -0700, David Daney wrote:
>>>
>>> From: David Daney
>>>
>>> Find out which PHYs belong to which BGX instance in the ACPI way.
>>>
>>> Set the MAC
Hi David,
On Sat, Aug 8, 2015 at 2:11 AM, David Daney wrote:
> On 08/07/2015 05:05 PM, Rafael J. Wysocki wrote:
[cut]
>>
>> It is actually useful to people as far as I can say.
>>
>> Also, if somebody is going to use properties with ACPI, why whould
>> they
Hi Mark,
On Fri, Aug 7, 2015 at 7:51 PM, Mark Rutland wrote:
> [Correcting the devicetree list address, which I typo'd in my original
> reply]
>
>> >> +static const char * const addr_propnames[] = {
>> >> + "mac-address",
>> >> + "local-mac-address",
>> >> + "address",
>> >> +};
>> >
>> > If t
On Thursday, August 06, 2015 10:48:48 AM Heikki Krogerus wrote:
> On Wed, Aug 05, 2015 at 05:02:18PM +0300, Andy Shevchenko wrote:
> > On Wed, 2015-08-05 at 16:39 +0300, Heikki Krogerus wrote:
> > > Marcos for easier creation of build-in property entries.
> > >
> > > Signed-off-by: Heikki Krogerus
| 14 +
> drivers/crypto/ccp/ccp-platform.c | 60 +---
> drivers/net/ethernet/amd/xgbe/xgbe-main.c | 27 +
> drivers/scsi/megaraid/megaraid_sas_fp.c | 8 +++
> drivers/scsi/ufs/unipro.h | 8 +++
> include/acpi/acpi_bus
On Friday, May 22, 2015 07:15:17 PM Suravee Suthikulanit wrote:
> On 5/22/2015 6:05 PM, Rafael J. Wysocki wrote:
> > On Friday, May 22, 2015 05:24:15 PM Suravee Suthikulanit wrote:
> >> Not sure if this went out earlier. So I am resending.
> >>
> >> On 5/
On Friday, May 22, 2015 05:24:15 PM Suravee Suthikulanit wrote:
> Not sure if this went out earlier. So I am resending.
>
> On 5/22/15 16:56, Rafael J. Wysocki wrote:
> >> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
> >> >index 39c485b..b9657af 100644
&
ct acpi_device
> *acpi_dev)
> if (!has_acpi_companion(dev))
> ACPI_COMPANION_SET(dev, acpi_dev);
>
> + if (acpi_check_dma(acpi_dev, &coherent))
> + arch_setup_dma_ops(dev, 0, 0, NULL, coherent);
> +
Well, so is this going to work fo
On Monday, May 18, 2015 05:38:17 PM Suravee Suthikulanit wrote:
> Hi Rafael,
>
> On 5/15/2015 6:53 PM, Rafael J. Wysocki wrote:
> > On Friday, May 15, 2015 04:23:09 PM Suravee Suthikulpanit wrote:
> >> [...]
> >> diff --git a/drivers/acpi/acpi_platform.c b/driver
On Monday, 18 of February 2008, Pierre Ossman wrote:
> The patch "[RTNETLINK]: Send a single notification on device state changes."
> kills (at least)
> the keyboard here. Everything seems to work fine in single user mode, but
> when init starts
> spawning of logins, the keyboard goes bye-bye. Ev
On Monday, 18 of February 2008, Jiri Kosina wrote:
> This reverts commit 45b503548210fe6f23e92b856421c2a3f05fd034.
>
> It contains deadlock, and breaks userspace applications (wpa_supplicant,
> networkmanager). References:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=10002
> http://bugzilla.ker
I wonder if commit 84cd2dfb04d23a961c5f537baa243fa54d0987ac
"sky2: remove check for PCI wakeup setting from BIOS" has anything to do with
it, btw.
supersud501, can you please check if the bug is still present in the current
Linus' tree?
--
To unsubscribe from this list: send the line "unsubscribe
On Sunday, 13 of January 2008, Andrew Morton wrote:
>
> 2.6.23 also has this warning in sky2_err_intr() but it doesn't trigger
> there. Rafael, I think we'd have to class this as a post-2.6.23
> regression.
Yes, it's been being tracked already.
--
To unsubscribe from this list: send the line "un
> http://bugzilla.kernel.org/show_bug.cgi?id=9721
On Saturday, 12 of January 2008, supersud501 wrote:
> I'll do the git-bisect (just downloading linux-2.6.git), but i forgot to
> mention one little thing: i'm using x64 version of kernel - does this
> play an important role?
No, it doesn't.
--
1 - 100 of 147 matches
Mail list logo
