[RFC PATCH] drm/bridge: anx7625: ANX_OUI[] can be static
Fixes: 152a82b6747f ("drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP
bridge driver")
Signed-off-by: kbuild test robot
---
anx7625.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bridge/analogix/anx7625.c
b/drivers/gpu/drm/bridge/analogix/anx7625.c
index 96adf3b89d7f0..a261f4d31ea88 100644
--- a/drivers/gpu/drm/bridge/analogix/anx7625.c
+++ b/drivers/gpu/drm/bridge/analogix/anx7625.c
@@ -728,7 +728,7 @@ static int anx7625_dpi_config(struct anx7625_data *ctx)
return ret;
}
-const u8 ANX_OUI[3] = { 0x00, 0x22, 0xB9 };
+static const u8 ANX_OUI[3] = { 0x00, 0x22, 0xB9 };
static int is_anx_dongle(struct anx7625_data *ctx)
{
u8 buf[3];
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 2/2] drm/bridge: anx7625: Add anx7625 MIPI DSI/DPI to DP bridge driver
Hi Xin, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [cannot apply to v5.4-rc3 next-20191011] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify the base tree in git format-patch, please see https://stackoverflow.com/a/37406982] url: https://github.com/0day-ci/linux/commits/Xin-Ji/dt-bindings-drm-bridge-anx7625-MIPI-to-DP-transmitter-binding/20191014-043019 reproduce: # apt-get install sparse # sparse version: v0.6.1-rc1-43-g0ccb3b4-dirty make ARCH=x86_64 allmodconfig make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' If you fix the issue, kindly add following tag Reported-by: kbuild test robot sparse warnings: (new ones prefixed by >>) >> drivers/gpu/drm/bridge/analogix/anx7625.c:731:10: sparse: sparse: symbol >> 'ANX_OUI' was not declared. Should it be static? Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
good day
I am Vice Chairman of Hang Seng Bank, I have Important Matter to Discuss with you concerning my late client, Died without a NEXT OF KIN. Send me your private email for full details information. email me at (infocar...@aim.com) Mail:infocar...@aim.com Regards Dr.Raymond Chien Kuo Fung ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: wlan-ng: fix exit return when sme->key_idx >= NUM_WEPKEYS
From: Colin Ian King
Currently the exit return path when sme->key_idx >= NUM_WEPKEYS is via
label 'exit' and this checks if result is non-zero, however result has
not been initialized and contains garbage. Fix this by replacing the
goto with a return with the error code.
Addresses-Coverity: ("Uninitialized scalar variable")
Fixes: 0ca6d8e74489 ("Staging: wlan-ng: replace switch-case statements with
macro")
Signed-off-by: Colin Ian King
---
drivers/staging/wlan-ng/cfg80211.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/wlan-ng/cfg80211.c
b/drivers/staging/wlan-ng/cfg80211.c
index eee1998c4b18..fac38c842ac5 100644
--- a/drivers/staging/wlan-ng/cfg80211.c
+++ b/drivers/staging/wlan-ng/cfg80211.c
@@ -469,10 +469,8 @@ static int prism2_connect(struct wiphy *wiphy, struct
net_device *dev,
/* Set the encryption - we only support wep */
if (is_wep) {
if (sme->key) {
- if (sme->key_idx >= NUM_WEPKEYS) {
- err = -EINVAL;
- goto exit;
- }
+ if (sme->key_idx >= NUM_WEPKEYS)
+ return -EINVAL;
result = prism2_domibset_uint32(wlandev,
DIDMIB_DOT11SMT_PRIVACYTABLE_WEPDEFAULTKEYID,
--
2.20.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding
Hi Xin Ji,
On Mon, Oct 14, 2019 at 03:02:48AM +, Xin Ji wrote:
> On Fri, Oct 11, 2019 at 03:54:18PM +0300, Laurent Pinchart wrote:
> > On Fri, Oct 11, 2019 at 01:21:43PM +0200, Andrzej Hajda wrote:
> >> On 11.10.2019 04:21, Xin Ji wrote:
> >>> The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
> >>> for portable device. It converts MIPI to DisplayPort 1.3 4K.
> >>>
> >>> You can add support to your board with binding.
> >>>
> >>> Example:
> >>> anx7625_bridge: encoder@58 {
> >>> compatible = "analogix,anx7625";
> >>> reg = <0x58>;
> >>> status = "okay";
> >>> panel-flags = <1>;
> >>> enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>;
> >>> reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>;
> >>> #address-cells = <1>;
> >>> #size-cells = <0>;
> >>>
> >>> port@0 {
> >>> reg = <0>;
> >>> anx_1_in: endpoint {
> >>> remote-endpoint = <&mipi_dsi>;
> >>> };
> >>> };
> >>>
> >>> port@3 {
> >>> reg = <3>;
> >>> anx_1_out: endpoint {
> >>> remote-endpoint = <&panel_in>;
> >>> };
> >>> };
> >>> };
> >>>
> >>> Signed-off-by: Xin Ji
> >>> ---
> >>> .../bindings/display/bridge/anx7625.yaml | 96
> >>> ++
> >>> 1 file changed, 96 insertions(+)
> >>> create mode 100644
> >>> Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> >>>
> >>> diff --git
> >>> a/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> >>> b/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> >>> new file mode 100644
> >>> index 000..fc84683
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> >>> @@ -0,0 +1,96 @@
> >>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> >>> +# Copyright 2019 Analogix Semiconductor, Inc.
> >>> +%YAML 1.2
> >>> +---
> >>> +$id: "http://devicetree.org/schemas/display/bridge/anx7625.yaml#";
> >>> +$schema: "http://devicetree.org/meta-schemas/core.yaml#";
> >>> +
> >>> +title: Analogix ANX7625 SlimPort (4K Mobile HD Transmitter)
> >>> +
> >>> +maintainers:
> >>> + - Xin Ji
> >>> +
> >>> +description: |
> >>> + The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
> >>> + designed for portable devices.
> >>> +
> >>> +properties:
> >>> + "#address-cells": true
> >>> + "#size-cells": true
> >>> +
> >>> + compatible:
> >>> +items:
> >>> + - const: analogix,anx7625
> >>> +
> >>> + reg:
> >>> +maxItems: 1
> >>> +
> >>> + panel-flags:
> >>> +description: indicate the panel is internal or external
> >>> +maxItems: 1
> >>> +
> >>> + interrupts:
> >>> +maxItems: 1
> >>> +
> >>> + enable-gpios:
> >>> +description: used for power on chip control, POWER_EN pin D2.
> >>> +maxItems: 1
> >>> +
> >>> + reset-gpios:
> >>> +description: used for reset chip control, RESET_N pin B7.
> >>> +maxItems: 1
> >>> +
> >>> + port@0:
> >>> +type: object
> >>> +description:
> >>> + A port node pointing to MIPI DSI host port node.
> >>> +
> >>> + port@1:
> >>> +type: object
> >>> +description:
> >>> + A port node pointing to MIPI DPI host port node.
> >>> +
> >>> + port@2:
> >>> +type: object
> >>> +description:
> >>> + A port node pointing to external connector port node.
> >>> +
> >>> + port@3:
> >>> +type: object
> >>> +description:
> >>> + A port node pointing to eDP port node.
> >>
> >>
> >> Decrypting available product brief[1], there are following physical lines:
> >>
> >> Input:
> >>
> >> - MIPI DSI/DPI - video data, are DSI and DPI lines shared?
> >
> > It would be much easier if we could have access to more complete
> > information. I believe the DSI and DPI pins could be muxed, but there
> > should be more DPI pins than DSI pins.
>
> Yes DPI pins more than DSI pins.
>
> >>
> >> - I2S - audio data,
> >>
> >> - I2C - control line,
> >>
> >> - ALERT/INTP - interrupt,
> >>
> >> - USB 3.1 SSRc/Tx - for USB forwarding,
> >>
> >> Output:
> >>
> >> - SS1, SS2,
> >>
> >> - SBU/AUX,
> >>
> >> - CC1/2.
> >>
> >>
> >> Having this information I try to understand ports defined by you:
> >>
> >> - port@2 you have defined as pointing to external port, but here the
> >> port should be rather subnode of ANX7625 - the chip has CC lines, see
> >> beginning of [2].
> >>
> >> - port@3 describes SS1, SS2 and SBU/AUX lines together, am I right? In
> >> USB-C binding SBU and SS lines are represented by different ports,
> >> different approach, but maybe better in this case.
> >
> > I believe that, when connected to a DP display (either DP or eDP), the
> > DisplayPort signals are output on SS1 and/or SS2. I this really wonder
> > if we need two separate ports for this, it seems that port@2 and port@3
> > should be merged.
>
> OK, I will merge the port@2 and port@3, and use a flag to indicate
[PATCH v3 0/7] PCI: PM: Move to D0 before calling pci_legacy_resume_early()
From: Bjorn Helgaas Dexuan, the important thing here is the first patch, which is your [1], which I modified by doing pci_restore_state() as well as setting to D0: pci_set_power_state(pci_dev, PCI_D0); pci_restore_state(pci_dev); I'm proposing some more patches on top. None are relevant to the problem you're solving; they're just minor doc and other updates in the same area. Rafael, if you have a chance to look at these, I'd appreciate it. I tried to make the doc match the code, but I'm no PM expert. [1] https://lore.kernel.org/r/ku1p153mb016637caead346f0aa8e3801bf...@ku1p153mb0166.apcp153.prod.outlook.com Dexuan Cui (1): PCI/PM: Always return devices to D0 when thawing Bjorn Helgaas (6): PCI/PM: Correct pci_pm_thaw_noirq() documentation PCI/PM: Clear PCIe PME Status even for legacy power management PCI/PM: Run resume fixups before disabling wakeup events PCI/PM: Make power management op coding style consistent PCI/PM: Wrap long lines in documentation PCI/MSI: Move power state check out of pci_msi_supported() Documentation/power/pci.rst | 38 +++--- drivers/pci/msi.c | 6 +-- drivers/pci/pci-driver.c| 99 ++--- 3 files changed, 71 insertions(+), 72 deletions(-) -- 2.23.0.700.g56cf767bdb-goog
[PATCH 2/7] PCI/PM: Correct pci_pm_thaw_noirq() documentation
From: Bjorn Helgaas According to the documentation, pci_pm_thaw_noirq() did not put the device into the full-power state and restore its standard configuration registers. This is incorrect, so update the documentation to match the code. Signed-off-by: Bjorn Helgaas --- Documentation/power/pci.rst | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Documentation/power/pci.rst b/Documentation/power/pci.rst index 0e2ef7429304..1525c594d631 100644 --- a/Documentation/power/pci.rst +++ b/Documentation/power/pci.rst @@ -600,17 +600,17 @@ using the following PCI bus type's callbacks:: respectively. -The first of them, pci_pm_thaw_noirq(), is analogous to pci_pm_resume_noirq(), -but it doesn't put the device into the full power state and doesn't attempt to -restore its standard configuration registers. It also executes the device -driver's pm->thaw_noirq() callback, if defined, instead of pm->resume_noirq(). +The first of them, pci_pm_thaw_noirq(), is analogous to pci_pm_resume_noirq(). +It puts the device into the full power state and restores its standard +configuration registers. It also executes the device driver's pm->thaw_noirq() +callback, if defined, instead of pm->resume_noirq(). The pci_pm_thaw() routine is similar to pci_pm_resume(), but it runs the device driver's pm->thaw() callback instead of pm->resume(). It is executed asynchronously for different PCI devices that don't depend on each other in a known way. -The complete phase it the same as for system resume. +The complete phase is the same as for system resume. After saving the image, devices need to be powered down before the system can enter the target sleep state (ACPI S4 for ACPI-based systems). This is done in -- 2.23.0.700.g56cf767bdb-goog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/7] PCI/PM: Clear PCIe PME Status even for legacy power management
From: Bjorn Helgaas
Previously, pci_pm_resume_noirq() cleared the PME Status bit in the Root
Status register only if the device had no driver or the driver did not
implement legacy power management. It should clear PME Status regardless
of what sort of power management the driver supports, so do this before
checking for legacy power management.
This affects Root Ports and Root Complex Event Collectors, for which the
usual driver is the PCIe portdrv, which implements new power management, so
this change is just on principle, not to fix any actual defects.
Fixes: a39bd851dccf ("PCI/PM: Clear PCIe PME Status bit in core, not PCIe port
driver")
Signed-off-by: Bjorn Helgaas
---
drivers/pci/pci-driver.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index d4ac8ce8c1f9..0c3086793e4e 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -941,12 +941,11 @@ static int pci_pm_resume_noirq(struct device *dev)
pci_pm_default_resume_early(pci_dev);
pci_fixup_device(pci_fixup_resume_early, pci_dev);
+ pcie_pme_root_status_cleanup(pci_dev);
if (pci_has_legacy_pm_support(pci_dev))
return pci_legacy_resume_early(dev);
- pcie_pme_root_status_cleanup(pci_dev);
-
if (drv && drv->pm && drv->pm->resume_noirq)
error = drv->pm->resume_noirq(dev);
--
2.23.0.700.g56cf767bdb-goog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/7] PCI/PM: Run resume fixups before disabling wakeup events
From: Bjorn Helgaas
pci_pm_resume() and pci_pm_restore() call pci_pm_default_resume(), which
runs resume fixups before disabling wakeup events:
static void pci_pm_default_resume(struct pci_dev *pci_dev)
{
pci_fixup_device(pci_fixup_resume, pci_dev);
pci_enable_wake(pci_dev, PCI_D0, false);
}
pci_pm_runtime_resume() does both of these, but in the opposite order:
pci_enable_wake(pci_dev, PCI_D0, false);
pci_fixup_device(pci_fixup_resume, pci_dev);
We should always use the same ordering unless there's a reason to do
otherwise. Change pci_pm_runtime_resume() to call pci_pm_default_resume()
instead of open-coding this, so the fixups are always done before disabling
wakeup events.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/pci-driver.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 0c3086793e4e..55acb658273f 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -1345,8 +1345,7 @@ static int pci_pm_runtime_resume(struct device *dev)
return 0;
pci_fixup_device(pci_fixup_resume_early, pci_dev);
- pci_enable_wake(pci_dev, PCI_D0, false);
- pci_fixup_device(pci_fixup_resume, pci_dev);
+ pci_pm_default_resume(pci_dev);
if (pm && pm->runtime_resume)
rc = pm->runtime_resume(dev);
--
2.23.0.700.g56cf767bdb-goog
[PATCH 6/7] PCI/PM: Wrap long lines in documentation
From: Bjorn Helgaas Documentation/power/pci.rst is wrapped to fit in 80 columns, but directory structure changes made a few lines longer. Wrap them so they all fit in 80 columns again. Signed-off-by: Bjorn Helgaas --- Documentation/power/pci.rst | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/Documentation/power/pci.rst b/Documentation/power/pci.rst index 1525c594d631..db41a770a2f5 100644 --- a/Documentation/power/pci.rst +++ b/Documentation/power/pci.rst @@ -426,12 +426,12 @@ pm->runtime_idle() callback. 2.4. System-Wide Power Transitions -- There are a few different types of system-wide power transitions, described in -Documentation/driver-api/pm/devices.rst. Each of them requires devices to be handled -in a specific way and the PM core executes subsystem-level power management -callbacks for this purpose. They are executed in phases such that each phase -involves executing the same subsystem-level callback for every device belonging -to the given subsystem before the next phase begins. These phases always run -after tasks have been frozen. +Documentation/driver-api/pm/devices.rst. Each of them requires devices to be +handled in a specific way and the PM core executes subsystem-level power +management callbacks for this purpose. They are executed in phases such that +each phase involves executing the same subsystem-level callback for every device +belonging to the given subsystem before the next phase begins. These phases +always run after tasks have been frozen. 2.4.1. System Suspend ^ @@ -636,12 +636,12 @@ System restore requires a hibernation image to be loaded into memory and the pre-hibernation memory contents to be restored before the pre-hibernation system activity can be resumed. -As described in Documentation/driver-api/pm/devices.rst, the hibernation image is loaded -into memory by a fresh instance of the kernel, called the boot kernel, which in -turn is loaded and run by a boot loader in the usual way. After the boot kernel -has loaded the image, it needs to replace its own code and data with the code -and data of the "hibernated" kernel stored within the image, called the image -kernel. For this purpose all devices are frozen just like before creating +As described in Documentation/driver-api/pm/devices.rst, the hibernation image +is loaded into memory by a fresh instance of the kernel, called the boot kernel, +which in turn is loaded and run by a boot loader in the usual way. After the +boot kernel has loaded the image, it needs to replace its own code and data with +the code and data of the "hibernated" kernel stored within the image, called the +image kernel. For this purpose all devices are frozen just like before creating the image during hibernation, in the prepare, freeze, freeze_noirq @@ -691,8 +691,8 @@ controlling the runtime power management of their devices. At the time of this writing there are two ways to define power management callbacks for a PCI device driver, the recommended one, based on using a -dev_pm_ops structure described in Documentation/driver-api/pm/devices.rst, and the -"legacy" one, in which the .suspend(), .suspend_late(), .resume_early(), and +dev_pm_ops structure described in Documentation/driver-api/pm/devices.rst, and +the "legacy" one, in which the .suspend(), .suspend_late(), .resume_early(), and .resume() callbacks from struct pci_driver are used. The legacy approach, however, doesn't allow one to define runtime power management callbacks and is not really suitable for any new drivers. Therefore it is not covered by this -- 2.23.0.700.g56cf767bdb-goog
[PATCH 5/7] PCI/PM: Make power management op coding style consistent
From: Bjorn Helgaas
Some of the power management ops use this style:
struct device_driver *drv = dev->driver;
if (drv && drv->pm && drv->pm->prepare(dev))
drv->pm->prepare(dev);
while others use this:
const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
if (pm && pm->runtime_resume)
pm->runtime_resume(dev);
Convert the first style to the second so they're all consistent. Remove
local "error" variables when unnecessary. No functional change intended.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/pci-driver.c | 76 +++-
1 file changed, 36 insertions(+), 40 deletions(-)
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 55acb658273f..abbf5c39cb9c 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -679,11 +679,11 @@ static bool pci_has_legacy_pm_support(struct pci_dev
*pci_dev)
static int pci_pm_prepare(struct device *dev)
{
- struct device_driver *drv = dev->driver;
struct pci_dev *pci_dev = to_pci_dev(dev);
+ const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
- if (drv && drv->pm && drv->pm->prepare) {
- int error = drv->pm->prepare(dev);
+ if (pm && pm->prepare) {
+ int error = pm->prepare(dev);
if (error < 0)
return error;
@@ -917,8 +917,7 @@ static int pci_pm_suspend_noirq(struct device *dev)
static int pci_pm_resume_noirq(struct device *dev)
{
struct pci_dev *pci_dev = to_pci_dev(dev);
- struct device_driver *drv = dev->driver;
- int error = 0;
+ const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
if (dev_pm_may_skip_resume(dev))
return 0;
@@ -946,17 +945,16 @@ static int pci_pm_resume_noirq(struct device *dev)
if (pci_has_legacy_pm_support(pci_dev))
return pci_legacy_resume_early(dev);
- if (drv && drv->pm && drv->pm->resume_noirq)
- error = drv->pm->resume_noirq(dev);
+ if (pm && pm->resume_noirq)
+ return pm->resume_noirq(dev);
- return error;
+ return 0;
}
static int pci_pm_resume(struct device *dev)
{
struct pci_dev *pci_dev = to_pci_dev(dev);
const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
- int error = 0;
/*
* This is necessary for the suspend error path in which resume is
@@ -972,12 +970,12 @@ static int pci_pm_resume(struct device *dev)
if (pm) {
if (pm->resume)
- error = pm->resume(dev);
+ return pm->resume(dev);
} else {
pci_pm_reenable_device(pci_dev);
}
- return error;
+ return 0;
}
#else /* !CONFIG_SUSPEND */
@@ -1038,16 +1036,16 @@ static int pci_pm_freeze(struct device *dev)
static int pci_pm_freeze_noirq(struct device *dev)
{
struct pci_dev *pci_dev = to_pci_dev(dev);
- struct device_driver *drv = dev->driver;
+ const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
if (pci_has_legacy_pm_support(pci_dev))
return pci_legacy_suspend_late(dev, PMSG_FREEZE);
- if (drv && drv->pm && drv->pm->freeze_noirq) {
+ if (pm && pm->freeze_noirq) {
int error;
- error = drv->pm->freeze_noirq(dev);
- suspend_report_result(drv->pm->freeze_noirq, error);
+ error = pm->freeze_noirq(dev);
+ suspend_report_result(pm->freeze_noirq, error);
if (error)
return error;
}
@@ -1066,8 +1064,8 @@ static int pci_pm_freeze_noirq(struct device *dev)
static int pci_pm_thaw_noirq(struct device *dev)
{
struct pci_dev *pci_dev = to_pci_dev(dev);
- struct device_driver *drv = dev->driver;
- int error = 0;
+ const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
+ int error;
if (pcibios_pm_ops.thaw_noirq) {
error = pcibios_pm_ops.thaw_noirq(dev);
@@ -1091,10 +1089,10 @@ static int pci_pm_thaw_noirq(struct device *dev)
if (pci_has_legacy_pm_support(pci_dev))
return pci_legacy_resume_early(dev);
- if (drv && drv->pm && drv->pm->thaw_noirq)
- error = drv->pm->thaw_noirq(dev);
+ if (pm && pm->thaw_noirq)
+ return pm->thaw_noirq(dev);
- return error;
+ return 0;
}
static int pci_pm_thaw(struct device *dev)
@@ -1165,24 +1163,24 @@ static int pci_pm_poweroff_late(struct device *dev)
static int pci_pm_poweroff_noirq(struct device *dev)
{
struct pci_dev *pci_dev = to_pci_dev(dev);
- struct device_driver *drv = dev->driver;
+ const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
if (dev_pm_smart_suspend_and_suspended(dev))
return 0;
- if (pci_has_legac
[PATCH 1/7] PCI/PM: Always return devices to D0 when thawing
From: Dexuan Cui pci_pm_thaw_noirq() is supposed to return the device to D0 and restore its configuration registers, but previously it only did that for devices whose drivers implemented the new power management ops. Hibernation, e.g., via "echo disk > /sys/power/state", involves freezing devices, creating a hibernation image, thawing devices, writing the image, and powering off. The fact that thawing did not return devices with legacy power management to D0 caused errors, e.g., in this path: pci_pm_thaw_noirq if (pci_has_legacy_pm_support(pci_dev)) # true for Mellanox VF driver return pci_legacy_resume_early(dev) # ... legacy PM skips the rest pci_set_power_state(pci_dev, PCI_D0) pci_restore_state(pci_dev) pci_pm_thaw if (pci_has_legacy_pm_support(pci_dev)) pci_legacy_resume drv->resume mlx4_resume ... pci_enable_msix_range ... if (dev->current_state != PCI_D0) # <--- return -EINVAL; which caused these warnings: mlx4_core a6d1:00:02.0: INTx is not supported in multi-function mode, aborting PM: dpm_run_callback(): pci_pm_thaw+0x0/0xd7 returns -95 PM: Device a6d1:00:02.0 failed to thaw: error -95 Return devices to D0 and restore config registers for all devices, not just those whose drivers support new power management. [bhelgaas: also call pci_restore_state() before pci_legacy_resume_early(), update comment, add stable tag, commit log] Link: https://lore.kernel.org/r/ku1p153mb016637caead346f0aa8e3801bf...@ku1p153mb0166.apcp153.prod.outlook.com Signed-off-by: Dexuan Cui Signed-off-by: Bjorn Helgaas Cc: sta...@vger.kernel.org # v4.13+ --- drivers/pci/pci-driver.c | 17 +++-- 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c index a8124e47bf6e..d4ac8ce8c1f9 100644 --- a/drivers/pci/pci-driver.c +++ b/drivers/pci/pci-driver.c @@ -1076,17 +1076,22 @@ static int pci_pm_thaw_noirq(struct device *dev) return error; } - if (pci_has_legacy_pm_support(pci_dev)) - return pci_legacy_resume_early(dev); - /* -* pci_restore_state() requires the device to be in D0 (because of MSI -* restoration among other things), so force it into D0 in case the -* driver's "freeze" callbacks put it into a low-power state directly. +* Both the legacy ->resume_early() and the new pm->thaw_noirq() +* callbacks assume the device has been returned to D0 and its +* config state has been restored. +* +* In addition, pci_restore_state() restores MSI-X state in MMIO +* space, which requires the device to be in D0, so return it to D0 +* in case the driver's "freeze" callbacks put it into a low-power +* state. */ pci_set_power_state(pci_dev, PCI_D0); pci_restore_state(pci_dev); + if (pci_has_legacy_pm_support(pci_dev)) + return pci_legacy_resume_early(dev); + if (drv && drv->pm && drv->pm->thaw_noirq) error = drv->pm->thaw_noirq(dev); -- 2.23.0.700.g56cf767bdb-goog
[PATCH 7/7] PCI/MSI: Move power state check out of pci_msi_supported()
From: Bjorn Helgaas
27e20603c54b ("PCI/MSI: Move D0 check into pci_msi_check_device()")
moved the power state check into pci_msi_check_device(), which was
subsequently renamed to pci_msi_supported(). This didn't change the
behavior, since both callers checked the power state.
However, it doesn't fit the current "pci_msi_supported()" name, which
should return what the device is capable of, independent of the power
state.
Move the power state check back into the callers for readability. No
functional change intended.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/msi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 0884bedcfc7a..20e9c729617c 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -861,7 +861,7 @@ static int pci_msi_supported(struct pci_dev *dev, int nvec)
if (!pci_msi_enable)
return 0;
- if (!dev || dev->no_msi || dev->current_state != PCI_D0)
+ if (!dev || dev->no_msi)
return 0;
/*
@@ -972,7 +972,7 @@ static int __pci_enable_msix(struct pci_dev *dev, struct
msix_entry *entries,
int nr_entries;
int i, j;
- if (!pci_msi_supported(dev, nvec))
+ if (!pci_msi_supported(dev, nvec) || dev->current_state != PCI_D0)
return -EINVAL;
nr_entries = pci_msix_vec_count(dev);
@@ -1058,7 +1058,7 @@ static int __pci_enable_msi_range(struct pci_dev *dev,
int minvec, int maxvec,
int nvec;
int rc;
- if (!pci_msi_supported(dev, minvec))
+ if (!pci_msi_supported(dev, minvec) || dev->current_state != PCI_D0)
return -EINVAL;
/* Check whether driver already requested MSI-X IRQs */
--
2.23.0.700.g56cf767bdb-goog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/2] dt-bindings: drm/bridge: anx7625: MIPI to DP transmitter binding
Hi Laurent Pinchart,
On Tue, Oct 15, 2019 at 01:16:10AM +0300, Laurent Pinchart wrote:
> Hi Xin Ji,
>
> On Mon, Oct 14, 2019 at 03:02:48AM +, Xin Ji wrote:
> > On Fri, Oct 11, 2019 at 03:54:18PM +0300, Laurent Pinchart wrote:
> > > On Fri, Oct 11, 2019 at 01:21:43PM +0200, Andrzej Hajda wrote:
> > >> On 11.10.2019 04:21, Xin Ji wrote:
> > >>> The ANX7625 is an ultra-low power 4K Mobile HD Transmitter designed
> > >>> for portable device. It converts MIPI to DisplayPort 1.3 4K.
> > >>>
> > >>> You can add support to your board with binding.
> > >>>
> > >>> Example:
> > >>> anx7625_bridge: encoder@58 {
> > >>> compatible = "analogix,anx7625";
> > >>> reg = <0x58>;
> > >>> status = "okay";
> > >>> panel-flags = <1>;
> > >>> enable-gpios = <&pio 45 GPIO_ACTIVE_HIGH>;
> > >>> reset-gpios = <&pio 73 GPIO_ACTIVE_HIGH>;
> > >>> #address-cells = <1>;
> > >>> #size-cells = <0>;
> > >>>
> > >>> port@0 {
> > >>> reg = <0>;
> > >>> anx_1_in: endpoint {
> > >>> remote-endpoint = <&mipi_dsi>;
> > >>> };
> > >>> };
> > >>>
> > >>> port@3 {
> > >>> reg = <3>;
> > >>> anx_1_out: endpoint {
> > >>> remote-endpoint = <&panel_in>;
> > >>> };
> > >>> };
> > >>> };
> > >>>
> > >>> Signed-off-by: Xin Ji
> > >>> ---
> > >>> .../bindings/display/bridge/anx7625.yaml | 96
> > >>> ++
> > >>> 1 file changed, 96 insertions(+)
> > >>> create mode 100644
> > >>> Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> > >>>
> > >>> diff --git
> > >>> a/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> > >>> b/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> > >>> new file mode 100644
> > >>> index 000..fc84683
> > >>> --- /dev/null
> > >>> +++ b/Documentation/devicetree/bindings/display/bridge/anx7625.yaml
> > >>> @@ -0,0 +1,96 @@
> > >>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > >>> +# Copyright 2019 Analogix Semiconductor, Inc.
> > >>> +%YAML 1.2
> > >>> +---
> > >>> +$id: "http://devicetree.org/schemas/display/bridge/anx7625.yaml#";
> > >>> +$schema: "http://devicetree.org/meta-schemas/core.yaml#";
> > >>> +
> > >>> +title: Analogix ANX7625 SlimPort (4K Mobile HD Transmitter)
> > >>> +
> > >>> +maintainers:
> > >>> + - Xin Ji
> > >>> +
> > >>> +description: |
> > >>> + The ANX7625 is an ultra-low power 4K Mobile HD Transmitter
> > >>> + designed for portable devices.
> > >>> +
> > >>> +properties:
> > >>> + "#address-cells": true
> > >>> + "#size-cells": true
> > >>> +
> > >>> + compatible:
> > >>> +items:
> > >>> + - const: analogix,anx7625
> > >>> +
> > >>> + reg:
> > >>> +maxItems: 1
> > >>> +
> > >>> + panel-flags:
> > >>> +description: indicate the panel is internal or external
> > >>> +maxItems: 1
> > >>> +
> > >>> + interrupts:
> > >>> +maxItems: 1
> > >>> +
> > >>> + enable-gpios:
> > >>> +description: used for power on chip control, POWER_EN pin D2.
> > >>> +maxItems: 1
> > >>> +
> > >>> + reset-gpios:
> > >>> +description: used for reset chip control, RESET_N pin B7.
> > >>> +maxItems: 1
> > >>> +
> > >>> + port@0:
> > >>> +type: object
> > >>> +description:
> > >>> + A port node pointing to MIPI DSI host port node.
> > >>> +
> > >>> + port@1:
> > >>> +type: object
> > >>> +description:
> > >>> + A port node pointing to MIPI DPI host port node.
> > >>> +
> > >>> + port@2:
> > >>> +type: object
> > >>> +description:
> > >>> + A port node pointing to external connector port node.
> > >>> +
> > >>> + port@3:
> > >>> +type: object
> > >>> +description:
> > >>> + A port node pointing to eDP port node.
> > >>
> > >>
> > >> Decrypting available product brief[1], there are following physical
> > >> lines:
> > >>
> > >> Input:
> > >>
> > >> - MIPI DSI/DPI - video data, are DSI and DPI lines shared?
> > >
> > > It would be much easier if we could have access to more complete
> > > information. I believe the DSI and DPI pins could be muxed, but there
> > > should be more DPI pins than DSI pins.
> >
> > Yes DPI pins more than DSI pins.
> >
> > >>
> > >> - I2S - audio data,
> > >>
> > >> - I2C - control line,
> > >>
> > >> - ALERT/INTP - interrupt,
> > >>
> > >> - USB 3.1 SSRc/Tx - for USB forwarding,
> > >>
> > >> Output:
> > >>
> > >> - SS1, SS2,
> > >>
> > >> - SBU/AUX,
> > >>
> > >> - CC1/2.
> > >>
> > >>
> > >> Having this information I try to understand ports defined by you:
> > >>
> > >> - port@2 you have defined as pointing to external port, but here the
> > >> port should be rather subnode of ANX7625 - the chip has CC lines, see
> > >> beginning of [2].
> >
