Re: [PATCH V2] net: phy: tja11xx: Add IRQ support to the driver

On Thu, Jun 13, 2019 at 05:42:53PM +0200, Marek Vasut wrote: > On 5/30/19 1:46 AM, Marek Vasut wrote: > > On 5/30/19 1:29 AM, Andrew Lunn wrote: > >> On Tue, May 28, 2019 at 11:33:33PM +0200, Marek Vasut wrote: > >>> On 5/28/19 11:22 PM, Andrew Lunn wrote: > >&g

Re: [PATCH V2] net: phy: tja11xx: Add IRQ support to the driver

On Tue, May 28, 2019 at 11:33:33PM +0200, Marek Vasut wrote: > On 5/28/19 11:22 PM, Andrew Lunn wrote: > >> The link detection on the TJA1100 (not TJA1101) seems unstable at best, > >> so I better use all the interrupt sources to nudge the PHY subsystem and > >>

Re: [PATCH V2] net: phy: tja11xx: Add IRQ support to the driver

> The link detection on the TJA1100 (not TJA1101) seems unstable at best, > so I better use all the interrupt sources to nudge the PHY subsystem and > have it check the link change. Then it sounds like you should just ignore interrupts and stay will polling for the TJA1100. Andrew

Re: [PATCH V2] net: phy: tja11xx: Add IRQ support to the driver

Add support for handling the TJA11xx PHY IRQ signal. > >>>> > >>>> Signed-off-by: Marek Vasut > >>>> Cc: Andrew Lunn > >>>> Cc: Florian Fainelli > >>>> Cc: Guenter Roeck > >>>> Cc: Heiner Kallweit >

Re: [PATCH V5] net: phy: tja11xx: Add TJA11xx PHY driver

On Mon, May 27, 2019 at 08:44:24AM -0700, Guenter Roeck wrote: > >+static u32 tja11xx_hwmon_in_config[] = { > >+HWMON_I_LCRIT_ALARM, > >+0 > >+}; > >+ > >+static const struct hwmon_channel_info tja11xx_hwmon_in = { > >+.type = hwmon_in, > >+.config =

Re: [PATCH V6] net: phy: tja11xx: Add TJA11xx PHY driver

On Fri, May 24, 2019 at 04:22:28PM +0200, Marek Vasut wrote: > Add driver for the NXP TJA1100 and TJA1101 PHYs. These PHYs are special > BroadRReach 100BaseT1 PHYs used in automotive. > > Signed-off-by: Marek Vasut > Cc: Andrew Lunn > Cc: Florian Fainelli > Cc: Guente

Re: [PATCH V5] net: phy: tja11xx: Add TJA11xx PHY driver

> Are all these subtleties documented anywhere ? The netdev FAQ. Andrew

Re: [PATCH V5] net: phy: tja11xx: Add TJA11xx PHY driver

> Well, it seems this patch is flagged in patchwork as "changes requested" > . I don't know what changes are requested though :-( Hi Marek The patch was submitted while net-next as closed. That is pretty much an automatic reject. Please submit it again, and add on the review tags you have

Re: [PATCH V5] net: phy: tja11xx: Add TJA11xx PHY driver

On Sat, May 18, 2019 at 06:50:48PM +0200, Marek Vasut wrote: > On 5/18/19 4:14 PM, Andrew Lunn wrote: > > On Sat, May 18, 2019 at 01:51:23AM +0200, Marek Vasut wrote: > >> Add driver for the NXP TJA1100 and TJA1101 PHYs. These PHYs are special > >> BroadRReach 100Bas

Re: [PATCH RFC 2/2] net: phy: sfp: Add HWMON support for module sensors

> > + case hwmon_power: > > + /* External calibration of receive power requires > > +* floating point arithmetic. Doing that in the kernel > > +* is not easy, so just skip it. If the module does > > +* not require external calibration, we can however

Re: [PATCH RFC 1/2] hwmon: Add support for power min, lcrit, min_alarm and lcrit_alarm

On Thu, Jun 28, 2018 at 03:42:36PM -0700, Guenter Roeck wrote: > On Thu, Jun 28, 2018 at 10:41:14PM +0200, Andrew Lunn wrote: > > Some sensors support reporting minimal and lower critical power, as > > well as alarms when these thresholds are reached. Add support for >

[PATCH RFC 0/2] HWMON support for SFP modules

: module OEM SFP-7000-85 rev 11.0 sn M1512220075 dc 160221 module FINISAR CORP. FTLF8524E2GNL rev A sn PW40MNN dc 160725 The anonymous module uses external calibration, while the FINISAR uses internal calibration. Thus both code paths have been tested. Andrew Lunn (2): hwmon: Add support for power

[PATCH RFC 1/2] hwmon: Add support for power min, lcrit, min_alarm and lcrit_alarm

Some sensors support reporting minimal and lower critical power, as well as alarms when these thresholds are reached. Add support for these attributes to the hwmon core. Signed-off-by: Andrew Lunn --- drivers/hwmon/hwmon.c | 4 include/linux/hwmon.h | 8 2 files changed, 12

[PATCH RFC 2/2] net: phy: sfp: Add HWMON support for module sensors

reading *_input and *_alarm properties requires i2c read operations. Signed-off-by: Andrew Lunn --- drivers/net/phy/sfp.c | 732 ++ include/linux/sfp.h | 72 - 2 files changed, 803 insertions(+), 1 deletion(-) diff --git a/drivers/net/phy/sfp.c b

Re: [v4 09/11] drivers/hwmon: Add PECI cputemp driver

> >>+#if IS_ENABLED(CONFIG_X86) > >>+#include > >>+#else > >>+#define INTEL_FAM6_HASWELL_X 0x3F > >>+#define INTEL_FAM6_BROADWELL_X 0x4F > >>+#define INTEL_FAM6_SKYLAKE_X 0x55 > >>+#endif > > > >The entire code is very Intel specific. Why this #if instead of > >making the driver dependent on

Re: [PATCH v3 2/4] mfd: add Gateworks System Controller core driver

> What about the 'reset' functionality? Is there something in the power > supply API for hooking in a GPIO based power switch (in my case it > would be i2c) as I would think that would be common for ATX supplies? > I didn't see anything in Documentation/power. > > This is what led me to the

Re: [PATCH v3 2/4] mfd: add Gateworks System Controller core driver

On Tue, Apr 03, 2018 at 08:48:27AM -0700, Tim Harvey wrote: > On Wed, Mar 28, 2018 at 8:14 AM, Tim Harvey wrote: > > The Gateworks System Controller (GSC) is an I2C slave controller > > implemented with an MSP430 micro-controller whose firmware embeds the > > following

Re: [PATCH v2 2/8] [PATCH 2/8] Documentations: dt-bindings: Add a document of PECI adapter driver for Aspeed AST24xx/25xx SoCs

On Tue, Mar 06, 2018 at 01:40:02PM +0100, Pavel Machek wrote: > Hi! > > > Signed-off-by: Jae Hyun Yoo > > --- > > .../devicetree/bindings/peci/peci-aspeed.txt | 73 > > ++ > > 1 file changed, 73 insertions(+) > > create mode 100644

Re: [RFC 2/4] mfd: add Gateworks System Controller core driver

> + dev_err(>dev, ">> 0x%02x %d\n", reg, ret); > + return ret; > + } > + dev_dbg(>dev, ">> 0x%02x=0x%02x (%d)\n", reg, val, retry); > + > +return 0; Hi Tim There appears to be a few spaces vs tabs issues in this file. Andrew -- To unsubscribe from

Re: [RFC 0/4] Add support for the Gateworks System Controller

Hi Tim Cool. I would say this is done right. > One issue I'm trying to figure out the best way to deal with is the > fact that the GSC can 'NAK' transactions occasionally which is why I > override the regmap read/write functions and provide retries. This > resolves the issue for the mfd core

Re: [RFC 0/4] Add support for the Gateworks System Controller

On Tue, Feb 27, 2018 at 05:21:10PM -0800, Tim Harvey wrote: > This series adds support for the Gateworks System Controller used on Gateworks > Laguna, Ventana, and Newport product families. > > The GSC is an MSP430 I2C slave controller whose firmware embeds the following > features: > - I/O

Re: [PATCH v2 7/8] [PATCH 7/8] drivers/hwmon: Add a generic PECI hwmon client driver

> But even with this change, it still needs to use delayed creation > because BMC side kernel doesn't know how many DIMMs are populated on > a remote server before the remote server completes its memory > training and testing in BIOS, but it needs to check the remote > server's CPU temperature as

Re: [PATCH v2 1/8] [PATCH 1/8] drivers/peci: Add support for PECI bus driver core

> >Is there a real need to do transfers in atomic context, or with > >interrupts disabled? > > > > Actually, no. Generally, this function will be called in sleep-able context > so this code is for an exceptional case handling. > > I'll rewrite this code like below: > if (in_atomic() ||

Re: [PATCH v2 1/8] [PATCH 1/8] drivers/peci: Add support for PECI bus driver core

> +static int peci_locked_xfer(struct peci_adapter *adapter, > + struct peci_xfer_msg *msg, > + bool do_retry, > + bool has_aw_fcs) > +{ > + ktime_t start, end; > + s64 elapsed_ms; > + int rc = 0; > + > + if

Re: [linux, dev-4.10, 6/6] drivers/hwmon: Add a driver for a generic PECI hwmon

On Thu, Jan 11, 2018 at 03:14:37PM -0800, Jae Hyun Yoo wrote: > On 1/11/2018 2:18 PM, Andrew Lunn wrote: > >>>>>+static const struct of_device_id peci_of_table[] = { > >>>>>+{ .compatible = "peci-hwmon", }, > >>>> >

Re: [linux, dev-4.10, 6/6] drivers/hwmon: Add a driver for a generic PECI hwmon

> > >>+static const struct of_device_id peci_of_table[] = { > > >>+ { .compatible = "peci-hwmon", }, > > > > > >This does not look like a reference to some piece of hardware. > > > > > > > This driver provides generic PECI hwmon function to which controller has > > PECI HW such as Aspeed or