From: Steffen Trumtrar
This is required to provide uuid based integrity functionality for:
ima_policy (fsuuid option) and the 'evmctl' command ('--uuid' option).
Co-developed-by: Oleksij Rempel
Co-developed-by: Juergen Borleis
Signed-off-by: Steffen Trumtrar
---
fs/ubi
This is V2 to support ima/evm uuid in ubifs.
- the previously used memcopy is now replaced by a helper function as suggested
by Andy
jb
From: Steffen Trumtrar
This is required to provide uuid based integrity functionality for:
ima_policy (fsuuid option) and the 'evmctl' command ('--uuid' option).
Signed-off-by: Steffen Trumtrar
Signed-off-by: Oleksij Rempel
Acked-by: Juergen Borleis
---
fs/ubifs/s
00 00 00 00 00 00 00 00 00 00 ||
0830 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ||
Juergen
--
Pengutronix e.K. | Juergen Borleis |
Steuerwalder Str. 21 | https://www.pengutronix.de/ |
31137 Hil
he
'map->debugfs_name' member should be NULL on the first call. So, it should
be safe to kfree() this member unconditionally prior allocating a new
string for this member.
Fixes: 2899872b627e ("regmap: debugfs: Fix memory leak in regmap_debugfs_init")
Signed-off-by: Juergen Borleis
--
-> internal use | |
| | | |
| \--> 5.0 V -o--> internal use | /--> 3.8 V --> PMIC |
| | | | |
| \>|-o--> 3.2 V --> internal use |
| |
Signed-off-by:
The eMMC is part of the 'TQma53' CPU card and powered by its on-board power
supply.
Signed-off-by: Juergen Borleis
---
arch/arm/boot/dts/imx53-tqma53.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/imx53-tqma53.dtsi
b/arch/arm/boot/dts/imx53-tqma53.
Signal needs SoC's internal pull down.
Signed-off-by: Juergen Borleis
---
arch/arm/boot/dts/imx53-tqma53.dtsi | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx53-tqma53.dtsi
b/arch/arm/boot/dts/imx53-tqma53.dtsi
index 02eb3f4b605de..1c5cd103
This series is a cleanup of the devicetree for the TQ's 'TQma53' CPU card
in conjunction with its 'mba53' development baseboard. The cleanup should also
simplify the use of the 'TQma53' CPU card for a customized baseboard instead of
the development baseboard.
Comments are welcome.
Juergen
The referenced 3.3 V regulator is a 3.2 V regulator and part of the 'TQma53'
CPU card instead of the development 'mba53' baseboard. So fix the voltage
and move it to where it belongs to.
Signed-off-by: Juergen Borleis
---
arch/arm/boot/dts/imx53-mba53.dts | 10 +
Signed-off-by: Juergen Borleis
---
arch/arm/boot/dts/imx53-mba53.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx53-mba53.dts
b/arch/arm/boot/dts/imx53-mba53.dts
index 11c61844d5d85..5a21562a2dc1b 100644
--- a/arch/arm/boot/dts/imx53-mba53.dts
+++ b
Signed-off-by: Juergen Borleis
---
arch/arm/boot/dts/imx53-tqma53.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx53-tqma53.dtsi
b/arch/arm/boot/dts/imx53-tqma53.dtsi
index 4aff91e31f288..eedeced3c8810 100644
--- a/arch/arm/boot/dts/imx53-tqma53
Signal has an external pullup and works with weakest settings (driver
strength and speed).
Signed-off-by: Juergen Borleis
---
arch/arm/boot/dts/imx53-mba53.dts | 7 +++
arch/arm/boot/dts/imx53-tqma53.dtsi | 1 -
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot
-board power supply is connected
to the SDHC2 IO lines only. The SD card socket is not part of the CPU card,
so the 'vmmc' info must be part of the baseboard devicetree.
Signed-off-by: Juergen Borleis
---
arch/arm/boot/dts/imx53-mba53.dts | 1 +
arch/arm/boot/dts/imx53-tqma53.dt
Signed-off-by: Juergen Borleis
---
arch/arm/boot/dts/imx53-mba53.dts | 33 +
arch/arm/boot/dts/imx53-tqma53.dtsi | 19 ++-
2 files changed, 19 insertions(+), 33 deletions(-)
diff --git a/arch/arm/boot/dts/imx53-mba53.dts
b/arch/arm/boot/dts
> /* 13.2 System Control and Status Registers
> * Multiply register number by 4 to get address offset.
> */
Maybe we should put this macro into a shared location because
in "net/dsa/tag_lan9303.c" there is already a "#define LAN9303_MAX_PORTS
3".
jb
--
Pen
my setup still
works.
Tested-by: Juergen Borleis
Cheers
Juergen
--
Pengutronix e.K. | Juergen Borleis |
Industrial Linux Solutions | http://www.pengutronix.de/ |
depends on NET_DSA
> + depends on NET_DSA && I2C
> select NET_DSA_SMSC_LAN9303
> select REGMAP_I2C
> ---help---
Thanks, but already found and fixed by Arnd Bergmann.
jb
--
Pengutronix e.K. | Juergen Borleis |
Industrial Linux Solutions | http://www.pengutronix.de/ |
e *dev, struct dsa_switch *ds;
> unsigned int source_port;
>
> - if (unlikely(!dst)) {
> - dev_warn_ratelimited(&dev->dev, "Dropping packet, due to
> missing switch tree device\n");
> - return NULL;
> - }
> -
>
r SPI). I've now compile time tested all module
and static variants (hopefully) and run-time tested the static variant and
the I2C module variant.
jb
--
Pengutronix e.K. | Juergen Borleis |
Industrial Linux Solutions | http://www.pengutronix.de/ |
In this mode the switch device and the internal phys will be managed via
I2C interface. The MDIO interface is still supported, but for the
(emulated) CPU port only.
Signed-off-by: Juergen Borleis
CC: devicet...@vger.kernel.org
CC: robh...@kernel.org
CC: mark.rutl...@arm.com
---
.../devicetree
When the LAN9303 device is in MDIO manged mode, all register accesses must
be done via MDIO.
Please note: this code is compile time tested only due to the absence of such
configured hardware. It is based on a patch from Stefan Roese from 2014.
Signed-off-by: Juergen Borleis
CC: devicet
ontrol the destination and the source of an ethernet packet.
Signed-off-by: Juergen Borleis
---
include/net/dsa.h | 1 +
net/dsa/Kconfig | 4 ++
net/dsa/Makefile | 1 +
net/dsa/dsa.c | 3 ++
net/dsa/dsa_priv.h| 3 ++
net/dsa/tag_lan93
The SMSC/Microchip LAN9303 is an ethernet switch device with one CPU port
and two external ethernet ports with built-in phys.
This driver uses the DSA framework, but is currently only capable of
separating the two external ports. There is no offload support yet.
Signed-off-by: Juergen Borleis
The LAN9303 is a three port 10/100 ethernet switch with integrated phys
for the two external ethernet ports. The third port is an RMII/MII
interface to a host master network interface (e.g. fixed link).
While the LAN9303 device itself supports offload packet processing, this
driver does not make u
The SMSC/Microchip LAN9303 is an ethernet switch device with one CPU port
and two external ethernet ports with built-in phys.
This driver uses the DSA framework, but is currently only capable of
separating the two external ports. There is no offload support yet.
Signed-off-by: Juergen Borleis
The LAN9303 is a three port 10/100 ethernet switch with integrated phys
for the two external ethernet ports. The third port is an RMII/MII
interface to a host master network interface (e.g. fixed link).
While the LAN9303 device itself supports offload packet processing, this
driver does not make u
In this mode the switch device and the internal phys will be managed via
I2C interface. The MDIO interface is still supported, but for the
(emulated) CPU port only.
Signed-off-by: Juergen Borleis
Reviewed-by: Andrew Lunn
CC: devicet...@vger.kernel.org
CC: robh...@kernel.org
CC: mark.rutl
ontrol the destination and the source of an ethernet packet.
Signed-off-by: Juergen Borleis
---
include/net/dsa.h | 1 +
net/dsa/Kconfig | 4 ++
net/dsa/Makefile | 1 +
net/dsa/dsa.c | 3 ++
net/dsa/dsa_priv.h| 3 ++
net/dsa/tag_lan93
When the LAN9303 device is in MDIO manged mode, all register accesses must
be done via MDIO.
Please note: this code is compile time tested only due to the absence of such
configured hardware. It is based on a patch from Stefan Roese from 2014.
Signed-off-by: Juergen Borleis
Reviewed-by: Andrew
gt;
> Actually, this doesn't even build. Please fix this and resubmit.
Sorry, did a temporary fix in 'dsa_priv.h'a and so this missing #include
slipped through. Fix in v5 is coming soon.
Regards,
Juergen
--
Pengutronix e.K. | Ju
The SMSC/Microchip LAN9303 is an ethernet switch device with one CPU port
and two external ethernet ports with built-in phys.
This driver uses the DSA framework, but is currently only capable of
separating the two external ports. There is no offload support yet.
Signed-off-by: Juergen Borleis
ontrol the destination and the source of an ethernet packet.
Signed-off-by: Juergen Borleis
---
include/net/dsa.h | 1 +
net/dsa/Kconfig | 4 ++
net/dsa/Makefile | 1 +
net/dsa/dsa.c | 3 ++
net/dsa/dsa_priv.h| 3 ++
net/dsa/tag_lan93
When the LAN9303 device is in MDIO manged mode, all register accesses must
be done via MDIO.
Please note: this code is compile time tested only due to the absence of such
configured hardware. It is based on a patch from Stefan Roese from 2014.
Signed-off-by: Juergen Borleis
Reviewed-by: Andrew
The LAN9303 is a three port 10/100 ethernet switch with integrated phys
for the two external ethernet ports. The third port is an RMII/MII
interface to a host master network interface (e.g. fixed link).
While the LAN9303 device itself supports offload packet processing, this
driver does not make u
In this mode the switch device and the internal phys will be managed via
I2C interface. The MDIO interface is still supported, but for the
(emulated) CPU port only.
Signed-off-by: Juergen Borleis
Reviewed-by: Andrew Lunn
CC: devicet...@vger.kernel.org
CC: robh...@kernel.org
CC: mark.rutl
ontrol the destination and the source of an ethernet packet.
Signed-off-by: Juergen Borleis
---
include/net/dsa.h | 1 +
net/dsa/Kconfig | 3 +
net/dsa/Makefile | 1 +
net/dsa/dsa.c | 3 +
net/dsa/dsa_priv.h| 3 +
net/dsa/tag_lan93
The SMSC/Microchip LAN9303 is an ethernet switch device with one CPU port
and two external ethernet ports with built-in phys.
This driver uses the DSA framework, but is currently only capable of
separating the two external ports. There is no offload support yet.
Signed-off-by: Juergen Borleis
The LAN9303 is a three port 10/100 ethernet switch with integrated phys
for the two external ethernet ports. The third port is an RMII/MII
interface to a host master network interface (e.g. fixed link).
While the LAN9303 device itself supports offload packet processing, this
driver does not make u
In this mode the switch device and the internal phys will be managed via
I2C interface. The MDIO interface is still supported, but for the
(emulated) CPU port only.
Signed-off-by: Juergen Borleis
CC: devicet...@vger.kernel.org
CC: robh...@kernel.org
CC: mark.rutl...@arm.com
---
.../devicetree
When the LAN9303 device is in MDIO manged mode, all register accesses must
be done via MDIO.
Please note: this code is compile time tested only due to the absence of such
configured hardware. It is based on a patch from Stefan Roese from 2014.
Signed-off-by: Juergen Borleis
CC: devicet
reg = <1>;
> > + label = "lan1;
> > + };
>
> These are not PHY nodes, so does this compatible string do anything?
I removed them and nothing changed.
Regards,
Juergen
--
Pengutronix e.K. | Juergen Borleis |
Industrial Linux Solutions | http://www.pengutronix.de/ |
es (MDIO emulation case):
Generic PHY 63fec000.etherne:00: attached PHY driver [Generic PHY]
(mii_bus:phy_addr=63fec000.etherne:00, irq=-1)
And for the fixed-link case:
Generic PHY fixed-0:00: attached PHY driver [Generic PHY]
(mii_bus:phy_addr=fixed-0:00, irq=-1)
Regards,
Juergen
--
Pe
Hi Andrew,
On Friday 07 April 2017 15:06:10 Andrew Lunn wrote:
> On Fri, Apr 07, 2017 at 10:14:59AM +0200, Juergen Borleis wrote:
> > To define the outgoing port and to discover the incoming port a regular
> > VLAN tag is used by the LAN9303. But its VID meaning is 'specia
The SMSC/Microchip LAN9303 is an ethernet switch device with one CPU port
and two external ethernet ports with built-in phys.
This driver uses the DSA framework, but is currently only capable of
separating the two external ports. There is no offload support yet.
Signed-off-by: Juergen Borleis
In this mode the switch device and the internal phys will be managed via
I2C interface. The MDIO interface is still supported, but for the
(emulated) CPU port only.
Signed-off-by: Juergen Borleis
---
.../devicetree/bindings/net/dsa/lan9303.txt| 64
drivers/net/dsa/Kconfig
When the LAN9303 device is in MDIO manged mode, all register accesses must
be done via MDIO.
Please note: this code is *untested* yet due to the absence of such
configured hardware. It is based on a patch of Stefan Roese from 2014.
Signed-off-by: Juergen Borleis
---
.../devicetree/bindings/net
ontrol the destination and the source of an ethernet packet.
Signed-off-by: Juergen Borleis
---
include/net/dsa.h | 1 +
net/dsa/Kconfig | 3 +
net/dsa/Makefile | 1 +
net/dsa/dsa.c | 3 +
net/dsa/dsa_priv.h| 3 +
net/dsa/tag_lan93
The LAN9303 is a three port 10/100 ethernet switch with integrated phys
for the two external ethernet ports. The third port is an RMII/MII
interface to a host master network interface (e.g. fixed link).
While the LAN9303 device itself supports offload packet processing, this
driver does not make u
#address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 { /* RMII fixed link to master */
> > + reg = <0>;
> > + label = "cpu";
> > + ethernet = <&master>;
> > + max-speed = <100>;
>
> max-speed does not do anything i think, since there is no adjust_link
> function.
Removed in v2.
Thanks.
Juergen
--
Pengutronix e.K. | Juergen Borleis |
Industrial Linux Solutions | http://www.pengutronix.de/ |
em in conjunction with calling lan9303_port_disable(). In v2 I do not
> > touch the phy anymore.
>
> So this is touching the BMCR_PDOWN bit? Using the #define would of
> helped explain this.
Okay.
Juergen
--
Pengutronix e.K. | Juergen Borleis |
Industrial Linux Solutions | http://www.pengutronix.de/ |
tween the MAC addresses
> > +* and the current ethertype field.
> > +*/
> > + skb_pull_rcsum(skb, 2 + 2);
> > + memmove(skb->data - ETH_HLEN, skb->data - (ETH_HLEN + LAN9303_TAG_LEN),
> > + 2 * ETH_ALEN);
> > + skb_push(skb, ETH_HL
ilt-in PHYs :)
Juergen
--
Pengutronix e.K. | Juergen Borleis |
Industrial Linux Solutions | http://www.pengutronix.de/ |
return -ENODEV;
> > + }
> > +
> > + return rc;
> > +}
> > +
> > +static void lan9303_port_disable(struct dsa_switch *ds, int port,
> > +struct phy_device *phy)
> > +{
> > + struct lan9303 *chip = ds_to_lan9303(ds);
> > + int rc;
> > +
> > + /* disable internal data handling */
> > + switch (port) {
> > + case 1:
> > + rc = lan9303_phy_reg_write(chip, chip->phy_addr_sel_strap + 1,
> > + 0, BIT(14) | BIT(11));
> > + rc += lan9303_write_switch_reg(chip, LAN9303_MAC_RX_CFG_1,
> > + 0x02);
> > + rc += lan9303_write_switch_reg(chip, LAN9303_MAC_TX_CFG_1,
> > + 0x56);
>
> It seems odd that port_enable does not touch the PHY, but port_disable
> does. What is this doing?
My experience is, the framework powers up the phys by its own in conjunction
with calling lan9303_port_enable(), but do not power down them in conjunction
with calling lan9303_port_disable(). In v2 I do not touch the phy anymore.
> [...]
> > +static int lan9303_register_phys(struct lan9303 *chip)
>
> This one place where the switch is being called a phy.
Renamed in v2.
> [...]
> > +static void lan9303_probe_reset_gpio(struct lan9303 *chip,
> > +struct device_node *np)
> > +{
> > + chip->reset_gpio = devm_gpiod_get_optional(chip->dev, "phy-reset",
>
> This is a reset for the switch, not a PHY in the switch i think. We
> have established a bit of a standard in DSA drivers to just call this
> "reset".
Renamed in v2.
Thanks
Juergen
--
Pengutronix e.K. | Juergen Borleis |
Linux Solutions for Science and Industry | Phone: +49-5121-206917-5128 |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de/ |
The SMSC/Microchip LAN9303 is an ethernet switch device with one CPU port
and two external ethernet ports with built-in phys.
This driver uses the DSA framework, but is currently only capable of
separating the two external ports. There is no offload support yet.
Signed-off-by: Juergen Borleis
In this mode the switch device and the internal phys will be managed via
I2C interface. The MDIO interface is still supported, but for the
(emulated) CPU port only.
Signed-off-by: Juergen Borleis
---
.../devicetree/bindings/net/dsa/lan9303.txt| 74 ++
drivers/net/phy
When the LAN9303 device is in MDIO manged mode, all register accesse must
be done via MDIO.
Please note: this code is *untested* yet due to the absence of such
configured hardware. It is based on a patch of Stefan Roese from 2014.
Signed-off-by: Juergen Borleis
---
.../devicetree/bindings/net
ontrol the destination and the source of an ethernet packet.
Signed-off-by: Juergen Borleis
---
include/net/dsa.h | 1 +
net/dsa/Kconfig | 3 +
net/dsa/Makefile | 1 +
net/dsa/dsa.c | 3 +
net/dsa/dsa_priv.h| 3 +
net/dsa/tag_lan93
The LAN9303 is a three port 10/100 ethernet switch with integrated phys
for the two external ethernet ports. The third port is an RMII/MII
interface to a host master network interface (e.g. fixed link).
While the LAN9303 device itself supports offload packet processing, this
driver does not make u
gt; + rtc = devm_rtc_device_register(&client->dev,
> +pcf85063_driver.driver.name,
> +&pcf85063_rtc_ops, THIS_MODULE);
>
> - return PTR_ERR_OR_ZERO(pcf85063->rtc);
> + return PTR_ERR_OR_ZERO(rtc);
> }
>
> static const struct i2c_device_id pcf85063_id[] = {
Reviewed-by: Juergen Borleis
jb
_get_clientdata(client);
> ^
Due to your removement of the useless century handling the last user of 'struct
pcf85063' is gone. Seems we can remove this struct entirely. What do you
think?
Regards,
Juergen
--
Pengutronix e.K. | Juergen Borleis |
Industrial Linux Solutions | http://www.pengutronix.de/ |
gs[6]);
> if (tm->tm_year < 70)
> tm->tm_year += 100; /* assume we are in 1970...2069 */
> - /* detect the polarity heuristically. see note above. */
> - pcf85063->c_polarity = (regs[5] & PCF85063_MO_C) ?
> - (tm->tm_yea
Just returned from the embedded world exhibition... Will test it.
Regards,
Juergen
--
Pengutronix e.K. | Juergen Borleis |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Check if the RTC signals an invalid time/date (due to a battery power loss
for example). In this case ignore the time/date until it is really set again.
Signed-off-by: Juergen Borleis
---
drivers/rtc/rtc-pcf85063.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/rtc/rtc
t. Make it more
clear why the read must happen in this way.
Signed-off-by: Juergen Borleis
---
drivers/rtc/rtc-pcf85063.c | 47 +-
1 file changed, 21 insertions(+), 26 deletions(-)
diff --git a/drivers/rtc/rtc-pcf85063.c b/drivers/rtc/rtc-pcf850
ff-by: Juergen Borleis
---
drivers/rtc/rtc-pcf85063.c | 78 --
1 file changed, 55 insertions(+), 23 deletions(-)
diff --git a/drivers/rtc/rtc-pcf85063.c b/drivers/rtc/rtc-pcf85063.c
index e0343e6..c5db231 100644
--- a/drivers/rtc/rtc-pcf85063.c
+++ b/driver
The PCF85063 RTC needs special treatment while setting or reading the
time/date:
- when reading the 7 time/date registers they are blocked from updating by
the 'one second' pulse internally. So reading all time/date registers
should happen in one turn to ensure reading is an atomic operatio
ode clearer and also more robust because it takes care of
> retransmissions for example.
Okay. Will have a look.
Regards,
Juergen
--
Pengutronix e.K. | Juergen Borleis |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubsc
ngs must happen that way.
Will check for the suggested smbus function.
Regards,
Juergen
--
Pengutronix e.K. | Juergen Borleis |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "
Use the function to read the whole time/date register in one turn and now
check if the RTC signals an invalid time/date (due to a battery power loss
for example). In this case ignore the time/date until it is really set
again.
Signed-off-by: Juergen Borleis
---
drivers/rtc/rtc-pcf85063.c | 45
The PCF85063 RTC needs special treatment while setting or reading the
time/date:
- while reading the 7 time/date registers they are blocked from updating by
the one second pulse internally. So reading all time/date registers should
happen in one turn to ensure reading is an atomic operation
When reading the seconds register, all time/date registers are frozen
until the year register is read. So, read all time/date registers in one
turn.
Signed-off-by: Juergen Borleis
---
drivers/rtc/rtc-pcf85063.c | 32
1 file changed, 32 insertions(+)
diff --git
ff-by: Juergen Borleis
---
drivers/rtc/rtc-pcf85063.c | 96 +++---
1 file changed, 73 insertions(+), 23 deletions(-)
diff --git a/drivers/rtc/rtc-pcf85063.c b/drivers/rtc/rtc-pcf85063.c
index abed934..0150e93 100644
--- a/drivers/rtc/rtc-pcf85063.c
+++ b/driver
tem and reboot it again
and again since an hour now and no more "scheduling while atomic" reports
occur. \o/
Thank you very much
Juergen
--
Pengutronix e.K. | Juergen Borleis |
Industrial Linux Solutions | http://www.pengutro
This function clears the reset the AUART unit is in after system start
to make it work.
Signed-off-by: Juergen Borleis
---
drivers/tty/serial/mxs-auart.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
index
and only release it from its reset state on the next
open().
Note: when the unit is also used as system console it is always 'in use',
so we cannot reset it on close().
Signed-off-by: Juergen Borleis
---
drivers/tty/serial/mxs-auart.c | 46 +++---
should be split into 2 or 3 separate patches:
> 1. Rename mxs_auart_reset()
> 2. Fix stale rx on re-open
> 3. Reset @ probe
Okay.
Regards,
Juergen
--
Pengutronix e.K. | Juergen Borleis |
Industrial Linux Solutions | http://www.pengu
Hi Peter,
On Friday 17 July 2015 15:10:06 Peter Hurley wrote:
> On 07/16/2015 03:40 AM, Juergen Borleis wrote:
> > Whenever the UART device driver gets closed from userland, the driver
> > disables the UART unit and then stops its clock to save power.
> >
> > The bit w
and only release it from its reset state on the next
open().
Signed-off-by: Juergen Borleis
---
Notes:
v3:
- missing newline added to an error message
v2:
- rename mxs_auart_do_reset() to mxs_auart_keep_reset() to better reflect
what it really does
- adapt the
Hi Stefan,
On Wednesday 15 July 2015 18:06:26 Stefan Wahren wrote:
> [...]
> > ---
>
> changelog for v2?
:) follows. Will send v3 which also contains the missing newline fix.
Thanks,
Juergen
--
Pengutronix e.K. | Juergen Borleis |
I
and only release it from its reset state on the next
open().
Signed-off-by: Juergen Borleis
---
drivers/tty/serial/mxs-auart.c | 38 ++
1 file changed, 30 insertions(+), 8 deletions(-)
diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-au
ell.
> [...]
> > + /* reset the unit if not aready done */
>
> Just a typo: already?
Ups. Yes. Will fix.
Thanks!
Juergen
--
Pengutronix e.K. | Juergen Borleis |
Industrial Linux Solutions | http://www.pengutro
and only release it from its reset state on the next
open().
Signed-off-by: Juergen Borleis
---
drivers/tty/serial/mxs-auart.c | 38 ++
1 file changed, 30 insertions(+), 8 deletions(-)
diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-au
e a valid choice but does not work due to hardware
restrictions. This results into a bad hardware behaviour (slow audio for
example). Feature tested on a i.MX25.
Signed-off-by: Juergen Borleis
---
sound/soc/fsl/fsl_ssi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/fsl
reading
the RTC time).
Note: this change is intended for development only to test the driver's
recovery capabilities. It is useless for regular use of the DryIce unit.
Signed-off-by: Juergen Borleis
Signed-off-by: Robert Schwebel
[rsc: got NDA clearance from Freescale]
---
drivers/rt
This code is required to recover the unit from a security violation.
Hopefully this code can recover the unit from a hardware related invalid
state as well.
Signed-off-by: Juergen Borleis
Signed-off-by: Robert Schwebel
[rsc: got NDA clearance from Freescale]
---
drivers/rtc/rtc-imxdi.c | 317
Be independent of the endianness of the kernel.
Signed-off-by: Juergen Borleis
---
drivers/rtc/rtc-imxdi.c | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/rtc/rtc-imxdi.c b/drivers/rtc/rtc-imxdi.c
index c666eab..0c2a064
The built-in RTC unit on some i.MX SoCs isn't an RTC only. It is also a tamper
monitor unit which can keep some (secret) keys. When it does its tamper
detection job and a security violation is detected, the whole DryICE unit
including the real-time counter locks completely. In this state the whole
Signed-off-by: Juergen Borleis
Signed-off-by: Robert Schwebel
[rsc: got NDA clearance from Freescale]
---
drivers/rtc/rtc-imxdi.c | 43 +++
1 file changed, 43 insertions(+)
diff --git a/drivers/rtc/rtc-imxdi.c b/drivers/rtc/rtc-imxdi.c
index 0c2a064
If the DryICE unit is locked it is impossibe to set the time. Provide an
error message for this case.
Signed-off-by: Juergen Borleis
Signed-off-by: Robert Schwebel
[rsc: got NDA clearance from Freescale]
---
drivers/rtc/rtc-imxdi.c | 27 ---
1 file changed, 24
Maybe the unit enters the hardware related state at runtime and not at
system boot time (after a power cycle).
Signed-off-by: Juergen Borleis
Signed-off-by: Robert Schwebel
[rsc: got NDA clearance from Freescale]
---
drivers/rtc/rtc-imxdi.c | 21 +++--
1 file changed, 19
Hi Alexandre,
On Wednesday 22 April 2015 01:26:15 Alexandre Belloni wrote:
> On 14/04/2015 at 11:11:51 +0200, Juergen Borleis wrote :
> > 2nd try, this time with a cover letter... m(
> >
> > The built-in RTC unit on some i.MX SoCs isn't an RTC only. It is also a
> &g
Hi Alexandre,
On Wednesday 22 April 2015 01:14:11 Alexandre Belloni wrote:
> On 14/04/2015 at 11:11:53 +0200, Juergen Borleis wrote :
> > This code is requiered to recover the unit from a security violation.
>
> required ^
Sure :)
> > [...]
> > +/* do a
> has happened ^
>
> > + * - "VALID STATE"
> > + * if the unit works as expected
> > + *
> > + * Everything stops when the unit enters the failure state including the
> > RTC + * counter (to be able to detect the time the sec
Hi,
On Friday 27 March 2015 12:44:03 Dong Aisheng wrote:
> On Fri, Mar 27, 2015 at 11:52:04AM +0100, Juergen Borleis wrote:
> > DMA and the required overhead on very small data blocks seems an
> > expensive operation. Due to erratum ENGCM07207 for i.MX25 and i.MX35 SoCs
>
Sorry for the noise, git confused me... See my other mails including the cover
letter...
jbe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
This code is requiered to recover the unit from a security violation.
Hopefully this code can recover the unit from a hardware related invalid
state as well.
Signed-off-by: Juergen Borleis
Signed-off-by: Robert Schwebel
[rsc: got NDA clearance from Freescale]
---
drivers/rtc/rtc-imxdi.c | 333
Signed-off-by: Juergen Borleis
Signed-off-by: Robert Schwebel
[rsc: got NDA clearance from Freescale]
---
drivers/rtc/rtc-imxdi.c | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/rtc/rtc-imxdi.c b/drivers/rtc/rtc-imxdi.c
index b04c64f
Signed-off-by: Juergen Borleis
Signed-off-by: Robert Schwebel
[rsc: got NDA clearance from Freescale]
---
drivers/rtc/rtc-imxdi.c | 43 +++
1 file changed, 43 insertions(+)
diff --git a/drivers/rtc/rtc-imxdi.c b/drivers/rtc/rtc-imxdi.c
index c666eab
Maybe the unit enters the hardware related state at runtime and not at
system boot time (after a power cycle).
Signed-off-by: Juergen Borleis
Signed-off-by: Robert Schwebel
[rsc: got NDA clearance from Freescale]
---
drivers/rtc/rtc-imxdi.c | 21 +++--
1 file changed, 19
1 - 100 of 121 matches
Mail list logo
