Re: [PATCH v2 1/1] PCI: Add hp_mmio_size and hp_mmio_pref_size parameters

On Wed, Oct 23, 2019 at 12:12:29PM +, Nicholas Johnson wrote: > Add kernel parameter pci=hpmmiosize=nn[KMG] to set MMIO bridge window > size for hotplug bridges. > > Add kernel parameter pci=hpmmioprefsize=nn[KMG] to set MMIO_PREF bridge > window size for hotplug bridges. > > Leave

Re: [PATCH 1/1] PCI: Add hp_mmio_size and hp_mmio_pref_size parameters

On Wed, Oct 23, 2019 at 10:33:42AM +, Nicholas Johnson wrote: > On Wed, Oct 23, 2019 at 01:03:59PM +0300, mika.westerb...@linux.intel.com > wrote: > > On Wed, Oct 23, 2019 at 09:57:17AM +, Nicholas Johnson wrote: > > > On Wed, Oct 23, 2019 at 12:47:43P

Re: [PATCH 1/1] PCI: Add hp_mmio_size and hp_mmio_pref_size parameters

On Wed, Oct 23, 2019 at 09:57:17AM +, Nicholas Johnson wrote: > On Wed, Oct 23, 2019 at 12:47:43PM +0300, mika.westerb...@linux.intel.com > wrote: > > On Wed, Oct 23, 2019 at 08:37:48AM +, Nicholas Johnson wrote: > > > } else if (!strncmp(

Re: [PATCH 1/1] PCI: Add hp_mmio_size and hp_mmio_pref_size parameters

On Wed, Oct 23, 2019 at 08:37:48AM +, Nicholas Johnson wrote: > } else if (!strncmp(str, "hpmemsize=", 10)) { > - pci_hotplug_mem_size = memparse(str + 10, ); > + pci_hotplug_mmio_size = > +

Re: [PATCH 0/1] Add support for setting MMIO PREF hotplug bridge size

On Wed, Oct 23, 2019 at 08:36:59AM +, Nicholas Johnson wrote: > This patch adds support for two new kernel parameters. This patch has > been in the making for quite some time, and has changed several times > based on feedback. > > I realised I was making the mistake of putting it as part of

Re: [PATCH v8 4/6] PCI: Allow extend_bridge_window() to shrink resource if necessary

On Wed, Oct 23, 2019 at 09:16:10AM +, Nicholas Johnson wrote: > On Tue, Oct 08, 2019 at 03:09:07PM +0300, mika.westerb...@linux.intel.com > wrote: > > On Fri, Jul 26, 2019 at 12:54:22PM +, Nicholas Johnson wrote: > > > Remove checks for resource size in

Re: [PATCH v8 6/6] PCI: Fix bug resulting in double hpmemsize being assigned to MMIO window

On Fri, Jul 26, 2019 at 12:55:03PM +, Nicholas Johnson wrote: > Background > == I don't think the above are needed. > Currently, the kernel can sometimes assign the MMIO_PREF window > additional size into the MMIO

Re: [PATCH v8 5/6] PCI: Add hp_mmio_size and hp_mmio_pref_size parameters

On Fri, Jul 26, 2019 at 12:54:44PM +, Nicholas Johnson wrote: > Add kernel parameter pci=hpmmiosize=nn[KMG] to set MMIO bridge window > size for hotplug bridges. > > Add kernel parameter pci=hpmmioprefsize=nn[KMG] to set MMIO_PREF bridge > window size for hotplug bridges. > > Leave

Re: [PATCH v8 4/6] PCI: Allow extend_bridge_window() to shrink resource if necessary

On Fri, Jul 26, 2019 at 12:54:22PM +, Nicholas Johnson wrote: > Remove checks for resource size in extend_bridge_window(). This is > necessary to allow the pci_bus_distribute_available_resources() to > function when the kernel parameter pci=hpmemsize=nn[KMG] is used to > allocate resources.

Re: [PATCH v8 3/6] PCI: Change extend_bridge_window() to set resource size directly

On Fri, Jul 26, 2019 at 12:54:01PM +, Nicholas Johnson wrote: > Change extend_bridge_window() to set resource size directly instead of > using additional resource lists. > > Because additional resource lists are optional resources, any algorithm > that requires guaranteed allocation that uses

Re: [PATCH v8 2/6] PCI: In extend_bridge_window() change available to new_size

On Fri, Jul 26, 2019 at 12:53:41PM +, Nicholas Johnson wrote: > In extend_bridge_window() change "available" parameter name to new_size. > This makes more sense as this parameter represents the new size for the > window. > > Signed-off-by: Nicholas Johnson Reviewed-by: Mika Westerberg

Re: [PATCH v8 1/6] PCI: Consider alignment of hot-added bridges when distributing available resources

Hi Nicholas, On Fri, Jul 26, 2019 at 12:53:19PM +, Nicholas Johnson wrote: > Rewrite pci_bus_distribute_available_resources to better handle bridges > with different resource alignment requirements. Pass more details > arguments recursively to track the resource start and end addresses >

Re: [PATCH v8 0/6] Patch series to support Thunderbolt without any BIOS support

On Fri, Oct 04, 2019 at 08:08:03AM -0500, Bjorn Helgaas wrote: > On Thu, Oct 03, 2019 at 03:19:46PM +0300, mika.westerb...@linux.intel.com > wrote: > > On Fri, Jul 26, 2019 at 12:52:58PM +, Nicholas Johnson wrote: > > > Patch series rebased to 5.3-rc1. > > >

Re: [PATCH v8 0/6] Patch series to support Thunderbolt without any BIOS support

On Fri, Jul 26, 2019 at 12:52:58PM +, Nicholas Johnson wrote: > Patch series rebased to 5.3-rc1. > > If possible, please have a quick read over while I am away (2019-07-27 > to mid 2019-08-04), so I can fix any mistakes or make simple changes to > get problems out of the way for a more

Re: [PATCH v6 1/4] PCI: Consider alignment of hot-added bridges when distributing available resources

On Wed, May 22, 2019 at 02:30:44PM +, Nicholas Johnson wrote: > Rewrite pci_bus_distribute_available_resources to better handle bridges > with different resource alignment requirements. Pass more details > arguments recursively to track the resource start and end addresses > relative to the

Re: [PATCH v6 1/4] PCI: Consider alignment of hot-added bridges when distributing available resources

On Sat, Jun 15, 2019 at 02:56:36PM -0500, Bjorn Helgaas wrote: > Mika, this patch changes code you added in 1a5767725cec ("PCI: > Distribute available resources to hotplug-capable bridges"). Is there > any chance you could help review this? Sure, I'll take a look and comment separately. > On

Re: [PATCH] PCI: Consider alignment of hot-added bridges when distributing available resources

Hi, Please indicate in the $subject that this is second version of the patch as explained in: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#the-canonical-patch-format For example here the $subject should look like [PATCH v2] PCI: Consider alignment of hot-added

Re: [PATCH] PCI: Consider alignment of hot-added bridges when distributing available resources

Hi Nicholas, On Thu, Jan 31, 2019 at 09:51:05AM +, Nicholas Johnson wrote: > New systems with Thunderbolt are starting to use native PCI enumeration. > Mika Westerberg's patch "PCI: Distribute available resources to hotplug > capable PCIe downstream ports" >

Re: Qemu Guest kernel 4.20-rc1 PCIe hotplug issue

On Wed, Nov 14, 2018 at 02:30:14PM +0100, Lukas Wunner wrote: > On Wed, Nov 14, 2018 at 11:52:25AM +0200, mika.westerb...@linux.intel.com > wrote: > > On Tue, Nov 13, 2018 at 03:57:47PM +, Shameerali Kolothum Thodi wrote: > > > > The smb_mb() thing is not that clear

Re: Qemu Guest kernel 4.20-rc1 PCIe hotplug issue

On Wed, Nov 14, 2018 at 02:30:14PM +0100, Lukas Wunner wrote: > On Wed, Nov 14, 2018 at 11:52:25AM +0200, mika.westerb...@linux.intel.com > wrote: > > On Tue, Nov 13, 2018 at 03:57:47PM +, Shameerali Kolothum Thodi wrote: > > > > The smb_mb() thing is not that clear

Re: Qemu Guest kernel 4.20-rc1 PCIe hotplug issue

On Tue, Nov 13, 2018 at 03:57:47PM +, Shameerali Kolothum Thodi wrote: > > The smb_mb() thing is not that clear (at least to me) because it is used > > in two places in the driver and both seem to be making write to > > ctrl->cmd_busy visible to other CPUs but I don't see where we deal with >

Re: Qemu Guest kernel 4.20-rc1 PCIe hotplug issue

On Tue, Nov 13, 2018 at 03:57:47PM +, Shameerali Kolothum Thodi wrote: > > The smb_mb() thing is not that clear (at least to me) because it is used > > in two places in the driver and both seem to be making write to > > ctrl->cmd_busy visible to other CPUs but I don't see where we deal with >

Re: Qemu Guest kernel 4.20-rc1 PCIe hotplug issue

On Tue, Nov 13, 2018 at 01:28:04PM +, Shameerali Kolothum Thodi wrote: > > > -Original Message- > > From: mika.westerb...@linux.intel.com > > [mailto:mika.westerb...@linux.intel.com] > > Sent: 13 November 2018 12:59 > > To: Shameerali Kolothum Thodi

Re: Qemu Guest kernel 4.20-rc1 PCIe hotplug issue

On Tue, Nov 13, 2018 at 01:28:04PM +, Shameerali Kolothum Thodi wrote: > > > -Original Message- > > From: mika.westerb...@linux.intel.com > > [mailto:mika.westerb...@linux.intel.com] > > Sent: 13 November 2018 12:59 > > To: Shameerali Kolothum Thodi

Re: Qemu Guest kernel 4.20-rc1 PCIe hotplug issue

On Tue, Nov 13, 2018 at 12:36:20PM +, Shameerali Kolothum Thodi wrote: > > @@ -156,9 +156,9 @@ static void pcie_do_write_cmd(struct controller *ctrl, > > u16 cmd, > > slot_ctrl |= (cmd & mask); > > ctrl->cmd_busy = 1; > > smp_mb(); > > + ctrl->slot_ctrl = slot_ctrl; > > Actually

Re: Qemu Guest kernel 4.20-rc1 PCIe hotplug issue

On Tue, Nov 13, 2018 at 12:36:20PM +, Shameerali Kolothum Thodi wrote: > > @@ -156,9 +156,9 @@ static void pcie_do_write_cmd(struct controller *ctrl, > > u16 cmd, > > slot_ctrl |= (cmd & mask); > > ctrl->cmd_busy = 1; > > smp_mb(); > > + ctrl->slot_ctrl = slot_ctrl; > > Actually

Re: Qemu Guest kernel 4.20-rc1 PCIe hotplug issue

+Lukas On Tue, Nov 13, 2018 at 11:45:42AM +, Shameerali Kolothum Thodi wrote: > Hi Mika, Hi, > Since the commit commit 720d6a671a6e("PCI: pciehp: Do not handle events > if interrupts are masked"), the hotplug support on Qemu Guest(4.120-rc1) > with a vfio passthrough device seems to be

Re: Qemu Guest kernel 4.20-rc1 PCIe hotplug issue

+Lukas On Tue, Nov 13, 2018 at 11:45:42AM +, Shameerali Kolothum Thodi wrote: > Hi Mika, Hi, > Since the commit commit 720d6a671a6e("PCI: pciehp: Do not handle events > if interrupts are masked"), the hotplug support on Qemu Guest(4.120-rc1) > with a vfio passthrough device seems to be

Re: [PATCH 2/2] thunderbolt: Mask ring interrupt properly when polling starts

actually > > unmasks it probably because of a copy-paste mistake. > > > > Mask the interrupt properly from now on. > > > > Fixes: 4ffe722eefcb ("thunderbolt: Add polling mode for rings") > > Signed-off-by: Mika Westerberg <mika.westerb...@linux.intel.com

Re: [PATCH 2/2] thunderbolt: Mask ring interrupt properly when polling starts

On Mon, Nov 27, 2017 at 04:21:34PM +, Bernat, Yehezkel wrote: > On Mon, 2017-11-27 at 14:48 +0300, Mika Westerberg wrote: > > When ring enters polling mode we are expected to mask the ring > > interrupt > > before the callback is called. However, the current code actually > > unmasks it

Re: [PATCH v2 00/10] spi-nor: intel-spi: Various fixes and enhancements

On Wed, Sep 13, 2017 at 10:11:21AM +0800, Bin Meng wrote: > Hi Joakim, > > On Tue, Sep 12, 2017 at 1:44 AM, Joakim Tjernlund > wrote: > > On Mon, 2017-09-11 at 02:41 -0700, Bin Meng wrote: > >> This series does several bug fixes and clean ups against the intel-spi

Re: [PATCH v2 00/10] spi-nor: intel-spi: Various fixes and enhancements

On Wed, Sep 13, 2017 at 10:11:21AM +0800, Bin Meng wrote: > Hi Joakim, > > On Tue, Sep 12, 2017 at 1:44 AM, Joakim Tjernlund > wrote: > > On Mon, 2017-09-11 at 02:41 -0700, Bin Meng wrote: > >> This series does several bug fixes and clean ups against the intel-spi > >> spi-nor driver, as well as

Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware upgrade

On Thu, May 25, 2017 at 03:03:07PM +0300, mika.westerb...@linux.intel.com wrote: > On Thu, May 25, 2017 at 11:04:08AM +0300, mika.westerb...@linux.intel.com > wrote: > > On Thu, May 25, 2017 at 10:20:10AM +0300, mika.westerb...@linux.intel.com > > wrote: > > > On Wed,

Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware upgrade

On Thu, May 25, 2017 at 03:03:07PM +0300, mika.westerb...@linux.intel.com wrote: > On Thu, May 25, 2017 at 11:04:08AM +0300, mika.westerb...@linux.intel.com > wrote: > > On Thu, May 25, 2017 at 10:20:10AM +0300, mika.westerb...@linux.intel.com > > wrote: > > > On Wed,

Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware upgrade

On Thu, May 25, 2017 at 11:04:08AM +0300, mika.westerb...@linux.intel.com wrote: > On Thu, May 25, 2017 at 10:20:10AM +0300, mika.westerb...@linux.intel.com > wrote: > > On Wed, May 24, 2017 at 07:32:45PM +, Jamet, Michael wrote: > > > I talked to our BIOS expert toda

Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware upgrade

On Thu, May 25, 2017 at 11:04:08AM +0300, mika.westerb...@linux.intel.com wrote: > On Thu, May 25, 2017 at 10:20:10AM +0300, mika.westerb...@linux.intel.com > wrote: > > On Wed, May 24, 2017 at 07:32:45PM +, Jamet, Michael wrote: > > > I talked to our BIOS expert toda

Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware upgrade

On Thu, May 25, 2017 at 10:20:10AM +0300, mika.westerb...@linux.intel.com wrote: > On Wed, May 24, 2017 at 07:32:45PM +, Jamet, Michael wrote: > > I talked to our BIOS expert today. Here is his advice to debugging further: > > > > It looks like something may have been wr

Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware upgrade

On Thu, May 25, 2017 at 10:20:10AM +0300, mika.westerb...@linux.intel.com wrote: > On Wed, May 24, 2017 at 07:32:45PM +, Jamet, Michael wrote: > > I talked to our BIOS expert today. Here is his advice to debugging further: > > > > It looks like something may have been wr

Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware upgrade

On Wed, May 24, 2017 at 07:32:45PM +, Jamet, Michael wrote: > I talked to our BIOS expert today. Here is his advice to debugging further: > > It looks like something may have been wrong from system (BIOS, FW, others...) > perspective. > On reboot need to enter EFI shell and check resources

Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware upgrade

On Wed, May 24, 2017 at 07:32:45PM +, Jamet, Michael wrote: > I talked to our BIOS expert today. Here is his advice to debugging further: > > It looks like something may have been wrong from system (BIOS, FW, others...) > perspective. > On reboot need to enter EFI shell and check resources

Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware upgrade

On Sat, May 20, 2017 at 09:15:17AM +, Levy, Amir (Jer) wrote: > > I created a udev rule that will automatically authorize the dock and cable. > > #dell cable > > ACTION=="add", SUBSYSTEM=="thunderbolt", ATTR{authorized}=="0", > > ATTR{vendor}=="0xd4", ATTR{device}=="0xb051",

Re: [PATCH 00/24] Thunderbolt security levels and NVM firmware upgrade

On Sat, May 20, 2017 at 09:15:17AM +, Levy, Amir (Jer) wrote: > > I created a udev rule that will automatically authorize the dock and cable. > > #dell cable > > ACTION=="add", SUBSYSTEM=="thunderbolt", ATTR{authorized}=="0", > > ATTR{vendor}=="0xd4", ATTR{device}=="0xb051",

Re: [PATCH v9 2/9] Input: goodix - reset device at init

On Fri, Oct 30, 2015 at 09:33:28AM -0700, Dmitry Torokhov wrote: > cpi_dev_add_driver_gpios() does not really help with generic drivers > (unless we keep adding more and more board specific data to them). How > about we keep track of names used and only allow conversion for the > first name used,

Re: [PATCH v9 2/9] Input: goodix - reset device at init

On Fri, Oct 30, 2015 at 09:33:28AM -0700, Dmitry Torokhov wrote: > cpi_dev_add_driver_gpios() does not really help with generic drivers > (unless we keep adding more and more board specific data to them). How > about we keep track of names used and only allow conversion for the > first name used,

Re: [PATCH v9 2/9] Input: goodix - reset device at init

On Mon, Oct 19, 2015 at 02:32:24PM +, Tirdea, Irina wrote: > > > > -Original Message- > > From: linux-input-ow...@vger.kernel.org > > [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of > > mika.westerb...@linux.intel.com > > Sent: 14 October

Re: [PATCH v9 2/9] Input: goodix - reset device at init

On Mon, Oct 19, 2015 at 02:32:24PM +, Tirdea, Irina wrote: > > > > -Original Message- > > From: linux-input-ow...@vger.kernel.org > > [mailto:linux-input-ow...@vger.kernel.org] On Behalf Of > > mika.westerb...@linux.intel.com > > Sent: 14 October

Re: [PATCH v9 2/9] Input: goodix - reset device at init

On Wed, Oct 14, 2015 at 02:18:20PM +0300, mika.westerb...@linux.intel.com wrote: > On Tue, Oct 13, 2015 at 11:23:03PM -0700, Dmitry Torokhov wrote: > > I understand why one might use acpi_dev_add_driver_gpios() to augment > > data in ACPI, however here we have completely differen

Re: [PATCH v9 2/9] Input: goodix - reset device at init

On Tue, Oct 13, 2015 at 11:23:03PM -0700, Dmitry Torokhov wrote: > I understand why one might use acpi_dev_add_driver_gpios() to augment > data in ACPI, however here we have completely different issue: driver > that expects named gpios gets returned gpio that has nothing to do with > what it

Re: [PATCH v9 2/9] Input: goodix - reset device at init

On Tue, Oct 13, 2015 at 11:23:03PM -0700, Dmitry Torokhov wrote: > I understand why one might use acpi_dev_add_driver_gpios() to augment > data in ACPI, however here we have completely different issue: driver > that expects named gpios gets returned gpio that has nothing to do with > what it

Re: [PATCH v9 2/9] Input: goodix - reset device at init

On Wed, Oct 14, 2015 at 02:18:20PM +0300, mika.westerb...@linux.intel.com wrote: > On Tue, Oct 13, 2015 at 11:23:03PM -0700, Dmitry Torokhov wrote: > > I understand why one might use acpi_dev_add_driver_gpios() to augment > > data in ACPI, however here we have completely differen

Re: [PATCH v9 2/9] Input: goodix - reset device at init

On Tue, Oct 13, 2015 at 08:54:12AM +, Tirdea, Irina wrote: > > > I did not use devm_gpiod_get_optional() in order to ignore more errors > > > than -ENOENT. This is needed because the ACPI gpio core will fall back > > > to indexed gpios if named gpios are not found. In the common case of > > >

Re: [PATCH v9 2/9] Input: goodix - reset device at init

On Tue, Oct 13, 2015 at 08:54:12AM +, Tirdea, Irina wrote: > > > I did not use devm_gpiod_get_optional() in order to ignore more errors > > > than -ENOENT. This is needed because the ACPI gpio core will fall back > > > to indexed gpios if named gpios are not found. In the common case of > > >

Re: [PATCH] i2c: designware: use enable on resume instead initialization

On Wed, Jun 24, 2015 at 12:56:19PM +, De Marchi, Lucas wrote: > Yeah, but it would be bad to ignore the problem as well. The way it is now > kills any possibility of using DW controller for reading sensors like > gyroscope, accelerometer, barometer that have higher sampling rate etc. I'll >

Re: [PATCH] i2c: designware: use enable on resume instead initialization

On Wed, Jun 24, 2015 at 12:56:19PM +, De Marchi, Lucas wrote: Yeah, but it would be bad to ignore the problem as well. The way it is now kills any possibility of using DW controller for reading sensors like gyroscope, accelerometer, barometer that have higher sampling rate etc. I'll try

Re: [PATCH V4] acpi:apd:add AMD ACPI2Platform device support for x86 system.

On Fri, Feb 06, 2015 at 08:34:52AM +0800, Ken Xue wrote: > >From 1a6a3a5c0815cb1f52ec0a2b9601edfa9bfebe81 Mon Sep 17 00:00:00 2001 > From: Ken Xue > Date: Fri, 6 Feb 2015 08:27:51 +0800 > Subject: [PATCH] acpi:apd:add AMD ACPI2Platform device support for x86 system. > > This new feature is to

Re: [PATCH V4] acpi:apd:add AMD ACPI2Platform device support for x86 system.

is to interpret AMD specific ACPI device to platform device such as I2C, UART, GPIO found on AMD CZ and later chipsets. It based on example intel LPSS. Now, it can support AMD I2C, UART and GPIO. Signed-off-by: Ken Xue ken@amd.com Acked-by: Mika Westerberg mika.westerb...@linux.intel.com

Re: [PATCH V4] acpi:apd:add AMD ACPI2Platform device support for x86 system.

On Thu, Feb 05, 2015 at 11:07:17AM +0800, Ken Xue wrote: > >From d22789f089ee644413a144633f368f45cb0ac9d8 Mon Sep 17 00:00:00 2001 > From: Ken Xue > Date: Thu, 5 Feb 2015 11:04:44 +0800 > Subject: [PATCH] acpi:apd:add AMD ACPI2Platform device support for x86 system. > > This new feature is to

Re: [PATCH V4] acpi:apd:add AMD ACPI2Platform device support for x86 system.

is to interpret AMD specific ACPI device to platform device such as I2C, UART found on AMD CZ and later chipsets. It based on example intel LPSS. Now, it can support AMD I2C UART. You are missing Signed-off-by here. Anyway looks good to me, Acked-by: Mika Westerberg mika.westerb

Re: [PATCH V2] acpi:apd:add AMD ACPI2Platform device support for x86 system.

On Tue, Feb 03, 2015 at 05:55:25PM +0800, Ken Xue wrote: > On Tue, 2015-02-03 at 11:53 +0200, mika.westerb...@linux.intel.com > wrote: > > On Tue, Feb 03, 2015 at 09:04:55AM +0800, Ken Xue wrote: > > > as you said, platform_drv_probe calls dev_pm_domain_attach(). but > >

Re: [PATCH V2] acpi:apd:add AMD ACPI2Platform device support for x86 system.

On Tue, Feb 03, 2015 at 09:04:55AM +0800, Ken Xue wrote: > as you said, platform_drv_probe calls dev_pm_domain_attach(). but > platform_drv_probe just is a default probe routine. Not all platform > device drivers use this probe routine. so, codes here may be still > necessary. Are you saying that

Re: [PATCH V2] acpi:apd:add AMD ACPI2Platform device support for x86 system.

On Tue, Feb 03, 2015 at 05:55:25PM +0800, Ken Xue wrote: On Tue, 2015-02-03 at 11:53 +0200, mika.westerb...@linux.intel.com wrote: On Tue, Feb 03, 2015 at 09:04:55AM +0800, Ken Xue wrote: as you said, platform_drv_probe calls dev_pm_domain_attach(). but platform_drv_probe just

Re: [PATCH V2] acpi:apd:add AMD ACPI2Platform device support for x86 system.

On Tue, Feb 03, 2015 at 09:04:55AM +0800, Ken Xue wrote: as you said, platform_drv_probe calls dev_pm_domain_attach(). but platform_drv_probe just is a default probe routine. Not all platform device drivers use this probe routine. so, codes here may be still necessary. Are you saying that for

Re: [PATCH V2] acpi:apd:add AMD ACPI2Platform device support for x86 system.

On Mon, Feb 02, 2015 at 05:50:52PM +0800, Ken Xue wrote: > >From b9654ecbfaebde00aee746a024eec9fe8de24b97 Mon Sep 17 00:00:00 2001 > From: Ken Xue > Date: Mon, 2 Feb 2015 17:32:24 +0800 > Subject: [PATCH] This new feature is to interpret AMD specific ACPI device to > platform device such as I2C,

Re: [PATCH V2] acpi:apd:add AMD ACPI2Platform device support for x86 system.

On Mon, Feb 02, 2015 at 05:50:52PM +0800, Ken Xue wrote: From b9654ecbfaebde00aee746a024eec9fe8de24b97 Mon Sep 17 00:00:00 2001 From: Ken Xue ken@amd.com Date: Mon, 2 Feb 2015 17:32:24 +0800 Subject: [PATCH] This new feature is to interpret AMD specific ACPI device to platform device

Re: [Linaro-acpi] How to pass I2C platform_data under ACPI

On Thu, Apr 03, 2014 at 03:34:30PM +0200, Arnd Bergmann wrote: > On Thursday 03 April 2014 14:38:33 mika.westerb...@linux.intel.com wrote: > > On Thu, Apr 03, 2014 at 11:25:34AM +, Pallala, Ramakrishna wrote: > > > >> In non ACPI environment I used to initialize

Re: How to pass I2C platform_data under ACPI

On Thu, Apr 03, 2014 at 11:25:34AM +, Pallala, Ramakrishna wrote: > >> In non ACPI environment I used to initialize the platform_data under > >> board or platforms files. Under ACPI how do I do that? > > > >If you can't extract that information from ACPI namespace, then one option > >is to

Re: How to pass I2C platform_data under ACPI

On Thu, Apr 03, 2014 at 08:10:40AM +, Pallala, Ramakrishna wrote: > Hi All, > > I am trying to enable a i2c client driver under ACPI. The device is being > enumerated behind adapter device and I am getting IRQ resource as well. > > The problem I have now is, how do I pass the platform data

Re: [Linaro-acpi] How to pass I2C platform_data under ACPI

On Thu, Apr 03, 2014 at 03:34:30PM +0200, Arnd Bergmann wrote: On Thursday 03 April 2014 14:38:33 mika.westerb...@linux.intel.com wrote: On Thu, Apr 03, 2014 at 11:25:34AM +, Pallala, Ramakrishna wrote: In non ACPI environment I used to initialize the platform_data under board

Re: How to pass I2C platform_data under ACPI

On Thu, Apr 03, 2014 at 08:10:40AM +, Pallala, Ramakrishna wrote: Hi All, I am trying to enable a i2c client driver under ACPI. The device is being enumerated behind adapter device and I am getting IRQ resource as well. The problem I have now is, how do I pass the platform data to

Re: How to pass I2C platform_data under ACPI

On Thu, Apr 03, 2014 at 11:25:34AM +, Pallala, Ramakrishna wrote: In non ACPI environment I used to initialize the platform_data under board or platforms files. Under ACPI how do I do that? If you can't extract that information from ACPI namespace, then one option is to pass platform

Re: Linux ACPI DSDT table editing tools

On Wed, Feb 20, 2013 at 07:36:32AM +, Pallala, Ramakrishna wrote: > I am looking for tools(Linux or w*s) for editing ACPI tables. > Can you advise me some good tools. Also I would like to know how BIOS > engineers populate the ACPI tables? Which tools they use? Dunno about the BIOS

Re: Linux ACPI DSDT table editing tools

On Wed, Feb 20, 2013 at 07:36:32AM +, Pallala, Ramakrishna wrote: I am looking for tools(Linux or w*s) for editing ACPI tables. Can you advise me some good tools. Also I would like to know how BIOS engineers populate the ACPI tables? Which tools they use? Dunno about the BIOS engineers