> > >>+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 Nuvoto
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", },
> >>>>
>
> +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 (!a
On Wed, Feb 21, 2018 at 08:16:00AM -0800, Jae Hyun Yoo wrote:
> This commit adds a dt-bindings document of PECI adapter driver for Aspeed
> AST24xx/25xx SoCs.
Hi Jae
It would be good to separate this into two. One binding document for a
generic adaptor, with a generic PECI bus, and generic client
> >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() || irqs
> 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 i
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 expan
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 driv
> + dev_err(&client->dev, ">> 0x%02x %d\n", reg, ret);
> + return ret;
> + }
> + dev_dbg(&client->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 u
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 Documentation/devicetree/bindings/pe
> The 'use case' we have been using this in for a couple years is that
> users who want to use this watchdog will enable it externally (we have
> a command in the bootloader) and if enabled the kernel driver (that
> I'm proposing here which we've been using out-of-tree) will register
> the watchdog
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 features:
> > - I/O expande
> 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 restar
> >>+#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 X
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
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
:
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
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
> > th
> > + 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
HWMON device names are not allowed to contain "-* \t\n". Add a helper
which will return true if passed an invalid character. It can be used
to massage a string into a hwmon compatible name by replacing invalid
characters with '_'.
Signed-off-by: Andrew Lunn
---
includ
reading *_input and *_alarm properties
requires i2c read operations.
Signed-off-by: Andrew Lunn
---
RFC->V1
Use __be16 when reading sensor
DIV_ROUND_CLOSEST()
Don't use devm_hwmon_* to fix lifetime issues
Replace invalid chars in hwmon name with _
---
drivers/net/phy/Kconfig | 1 +
drivers
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
The enum hwmon_temp_lcrit_alarm exists, but the BIT definition is
missing.
Signed-off-by: Andrew Lunn
---
include/linux/hwmon.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/hwmon.h b/include/linux/hwmon.h
index e5fd2707b6df..1b74ad11a5a4 100644
--- a/include/linux/hwmon.h
internal calibration. Thus both code paths have been tested.
Due to the cross subsystem nature of these patches, as discussed with
the RFC, it is hoped Guenter Roeck will ACK the patches, and then Dave
Miller will merge them all via net-next.
Andrew Lunn (4):
hwmon: Add missing HWMON_T_LCRIT_ALARM
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
On Wed, May 22, 2019 at 11:48:06PM +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
> 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 receiv
> Are all these subtleties documented anywhere ?
The netdev FAQ.
Andrew
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
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 = tja11xx_hwmon_
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
>
> 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
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
> >>
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
34 matches
Mail list logo
