Hi!
> From: Aditya Pakki
>
> [ Upstream commit 0c85a7e87465f2d4cbc768e245f4f45b2f299b05 ]
>
> In case of rs failure in rds_send_remove_from_sock(), the 'rm' resource
> is freed and later under spinlock, causing potential use-after-free.
> Set the free pointer to NULL to avoid undefined behavior
Hi!
> In talking to the Debian Developer Mr. Federico Ceratto, since I have
> been unable to get a hold of the Ofono Maintainers, the best course of
> action for packaging mmsd into Debian is to simply fork the project and
> submit my version upstream for packaging in Debian. My repository is
> he
On Fri 2021-03-26 16:13:51, Zhang Jianhua wrote:
> If CONFIG_ATH9K=y, the following errors will be seen while compiling
> gpio.c
>
> drivers/net/wireless/ath/ath9k/gpio.o: In function `ath_deinit_leds':
> gpio.c:(.text+0x604): undefined reference to `led_classdev_unregister'
> gpio.c:(.text+0x604)
Hi!
> > index e201b4b1655a..46704c341b17 100644
> > --- a/arch/arc/include/asm/cacheflush.h
> > +++ b/arch/arc/include/asm/cacheflush.h
> > @@ -112,6 +112,6 @@ do {
> > \
> > } while (0)
> >
> > #define copy_from_user_page(vma,
dev_get_mac_address() does not always initialize whole
structure. Unfortunately, other code copies such structure to
userspace, leaking information. Fix it.
Signed-off-by: Pavel Machek (CIP)
Cc: sta...@kernel.org
diff --git a/net/core/dev.c b/net/core/dev.c
index 6c5967e80132..28283a9eb63a
Bitfield manipulation in enetc_mac_config() looks wrong. Fix
it. Untested.
Signed-off-by: Pavel Machek (CIP)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc_pf.c
b/drivers/net/ethernet/freescale/enetc/enetc_pf.c
index 224fc37a6757..b85079493933 100644
--- a/drivers/net/ethernet
Hi!
> Add support for controlling the LEDs connected to several families of
> Marvell PHYs via Linux LED API. These families currently are: 88E1112,
> 88E1116R, 88E1118, 88E1121R, 88E1149R, 88E1240, 88E1318S, 88E1340S,
> 88E1510, 88E1545 and 88E1548P.
>
> This does not yet add support for compoun
HI!
> Many an ethernet PHY chip has pins dedicated for LEDs. On some PHYs it
> can be configured via registers whether the LED should be ON, OFF, or
> whether its state should depend on events within the chip (link, rx/tx
> activity and so on).
>
> Add support for probing such LEDs.
>
> A PHY dr
On Fri 2020-10-30 12:44:33, Marek Behún wrote:
> Add a new integer member phyindex to struct phy_device. This member is
> unique for every phy_device. Atomic incrementation occurs in
> phy_device_register.
>
> This can be used for example in LED sysfs API. The LED subsystem names
> each LED in for
Hi!
> Add support for HW offloading of the netdev trigger.
>
> We need to change spinlock to mutex, because if spinlock is used, the
> trigger_offload() method cannot sleep, which can happen for ethernet
> PHYs.
Is that bugfix or just needed for offloading? Should be separate patch
in any case.
Hi!
> If the trigger with given configuration cannot be offloaded, the method
> should return -EOPNOTSUPP, in which case the trigger must blink the LED
> in SW.
>
> Signed-off-by: Marek Behún
> +
> +If the second argument (enable) to the trigger_offload() method is false, any
> +active HW offlo
On Fri 2020-10-30 12:44:30, Marek Behún wrote:
> Use bit fields members in struct led_netdev_data instead of one mode
> member and set_bit/clear_bit/test_bit functions. These functions are
> suitable for longer or variable length bit arrays.
They also provide atomicity guarantees. If you can expla
Can we get some kind of common prefix for the subjects?
> This report is generated by a bot. It may contain errors.
It is less useful than average lkml mail, so it should be easy to
filter.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzk
On Thu 2021-02-11 13:36:16, Heiner Kallweit wrote:
> On 11.02.2021 13:17, Pavel Machek wrote:
> > On Thu 2021-01-14 12:05:21, Heiner Kallweit wrote:
> >> On 14.01.2021 11:41, claudiu.bez...@microchip.com wrote:
> >>>
> >>>
> >>> On
On Thu 2021-01-14 12:05:21, Heiner Kallweit wrote:
> On 14.01.2021 11:41, claudiu.bez...@microchip.com wrote:
> >
> >
> > On 14.01.2021 12:25, Russell King - ARM Linux admin wrote:
> >>
> >> As I've said, if phylib/PHY driver is not restoring the state of the
> >> PHY on resume from suspend-to-ra
ma
> identifiers and incorrectly allows JSON pointers to begin without a '/'.
> Let's fix this before it becomes a problem when jsonschema module is
> fixed.
>
> Converted with:
> perl -p -i -e 's/yaml#definitions/yaml#\/definitions/g' `find
&g
Hi!
> In KSZ9131 PHY it is possible to control LEDs blink behavior via
> LED mode behavior and select registers. Add DTS properties plus handles
> of them inside micrel PHY driver.
>
> I've some concerns about passing raw register values into LED mode
> select and behavior. It can be passed via a
Hi!
> General description
>
> This is the result of development and maintenance of task isolation
> functionality that originally started based on task isolation patch
> v15 and was later updated to include v16. It provided predictable
> environment for userspace tasks running on arm64 processors
> +/* FIXME: Blinking rate is shared by all LEDs on a PHY. Should we check
> whether
> + * another LED is currently blinking with incompatible rate? It would be
> cleaner
> + * if we in this case failed to offload blinking this LED.
> + * But consider this situation:
> + * 1. user sets LED[1]
On Fri 2020-10-30 12:44:29, Marek Behún wrote:
> The trigger_data struct is allocated with kzalloc, so we do not need to
> explicitly set members to zero.
>
> Signed-off-by: Marek Behún
Acked-by: Pavel Machek
--
http://www.livejournal.com/~pavelmachek
signature.asc
Descript
Hi!
> > > What are your ideas about this problem?
> > >
> > > Marek
> >
> > BTW option b) and c) can be usable if we create a new utility, ledtool,
> > to report infromation about LEDs and configure LEDs.
> >
> > In that case it does not matter if the LED is named
> > ethernet-adapter0:red:ac
Hi!
> > What I am wondering is how should we select a name for the device part
> > of the LED for network devices, when network namespaces are enabled.
> >
> > a) We could just use the interface name (eth0:yellow:activity). The
> >problem is what should happen when the interface is renamed, o
Hi!
> > > +++ b/drivers/net/can/ctucanfd/Kconfig
> > > @@ -21,4 +21,15 @@ config CAN_CTUCANFD_PCI
> > > PCIe board with PiKRON.com designed transceiver riser shield is
> > > available at https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd .
> > >
> > > +config CAN_CTUCANFD_PLATFORM
> > > + trist
Hi!
> +++ b/drivers/net/can/ctucanfd/Kconfig
> @@ -21,4 +21,15 @@ config CAN_CTUCANFD_PCI
> PCIe board with PiKRON.com designed transceiver riser shield is
> available
> at https://gitlab.fel.cvut.cz/canbus/pcie-ctu_can_fd .
>
> +config CAN_CTUCANFD_PLATFORM
> + tristate "CT
Hi!
> @@ -12,4 +12,13 @@ config CAN_CTUCANFD
>
> if CAN_CTUCANFD
>
> +config CAN_CTUCANFD_PCI
> + tristate "CTU CAN-FD IP core PCI/PCIe driver"
> + depends on PCI
> + help
> + This driver adds PCI/PCIe support for CTU CAN-FD IP core.
> + The project providing FPGA des
On Thu 2020-10-22 10:36:21, Pavel Pisa wrote:
> CTU CAN FD IP core documentation based on Martin Jeřábek's diploma theses
> Open-source and Open-hardware CAN FD Protocol Support
> https://dspace.cvut.cz/handle/10467/80366
> .
> ---
> .../ctu/FSM_TXT_Buffer_user.png | Bin 0 -> 174807
Hi!
> From: Martin Jerabek
>
> This driver adds support for the CTU CAN FD open-source IP core.
> More documentation and core sources at project page
> (https://gitlab.fel.cvut.cz/canbus/ctucanfd_ip_core).
> The core integration to Xilinx Zynq system as platform driver
> is available (https://gi
ge
>
>http://canbus.pages.fel.cvut.cz/
>
> Signed-off-by: Pavel Pisa
> Reviewed-by: Rob Herring
1,2: Acked-by: Pavel Machek
--
http://www.livejournal.com/~pavelmachek
signature.asc
Description: Digital signature
Hi!
> +static int idt82p33_adjwritephase(struct ptp_clock_info *ptp, s32
> +offsetNs) {
adj_write_phase?
> + struct idt82p33_channel *channel =
> + container_of(ptp, struct idt82p33_channel, caps);
> + struct idt82p33 *idt82p33 = channel->idt82p33;
> + s64 offsetInFs;
>
Hi!
> Another round of wack-a-mole. The json-schema default is additional
> unknown properties are allowed, but for DT all properties should be
> defined.
for leds:
Acked-by: Pavel Machek
I assume you apply it..?
Hi!
It seems
commit fb3a780e7a76cf8efb055f8322ec039923cee41f
Author: Yuusuke Ashizuka
Date: Thu Aug 20 18:43:07 2020 +0900
ravb: Fixed to be able to unload modules
causes problems in at least -cip-rt kernels. (I'd have to verify it is
present in -cip and plain -stable). Symptoms are like
Hi!
> Many an ethernet PHY supports various HW control modes for LEDs
> connected directly to the PHY chip.
>
> This patch adds code for registering such LEDs when described in device
> tree and also adds a new private LED trigger called phydev-hw-mode.
> When this trigger is enabled for a LED, t
On Tue 2020-09-22 12:54:20, Saeed Mahameed wrote:
> On Mon, 2020-09-21 at 22:54 -0700, Saeed Mahameed wrote:
> > On Mon, 2020-09-21 at 13:41 +0200, Pavel Machek wrote:
> > > The last return statement is unreachable code. I'm not sure if it
> > > will
> > >
The last return statement is unreachable code. I'm not sure if it will
provoke any warnings, but it looks ugly.
Signed-off-by: Pavel Machek (CIP)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c
b/drivers/net/ethernet/mellanox/mlx5/core/lib/clock.c
index 2d55b7c
Hi!
> I have been thinking about another way to implement ABI for HW control
> of ethernet PHY connected LEDs.
>
> This proposal is inspired by the fact that for some time there is a
> movement in the kernel to do transparent HW offloading of things (DSA
> is an example of that).
And it is good
On Wed 2020-09-09 18:25:51, Marek Behún wrote:
> This patch adds support for controlling the LEDs connected to several
> families of Marvell PHYs via the PHY HW LED trigger API. These families
> are: 88E1112, 88E1121R, 88E1240, 88E1340S, 88E1510 and 88E1545. More can
> be added.
>
> This patch doe
Hi!
> > We already have different support for blinking in LED subsystem. Lets use
> > that.
>
> You are assuming we have full software control of the LED, we can turn
> it on and off. That is not always the case. But there is sometimes a
> mode which the hardware blinks the LED.
Please see "tim
Hi!
> Okay, so the netdev trigger offers modes `link`, `rx`, `tx`.
> You can enable/disable either of these (via separate sysfs files). `rx`
> and `tx` blink the LED, `link` turns the LED on if the interface is
> linked.
I wonder if people really need separate rx and tx, but... this sounds
reason
On Thu 2020-09-10 15:15:41, Andrew Lunn wrote:
> On Thu, Sep 10, 2020 at 02:23:41PM +0200, Pavel Machek wrote:
> > On Wed 2020-09-09 18:25:51, Marek Behún wrote:
> > > This patch adds support for controlling the LEDs connected to several
> > > families of Marvell PHYs
Hi!
> Add nodes for the green and yellow LEDs that are connected to the
> ethernet PHY chip on Turris MOX A.
>
> Signed-off-by: Marek Behún
> ---
> .../dts/marvell/armada-3720-turris-mox.dts| 23 +++
> 1 file changed, 23 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/ma
led_led_ops and set the member led_ops in struct
> phy_driver to point to that structure.
>
> Signed-off-by: Marek Behún
Acked-by: Pavel Machek
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
s
gt; */
> int phy_device_register(struct phy_device *phydev)
> {
> + static atomic_t phyindex;
> int err;
>
> err = mdiobus_register_device(&phydev->mdio);
I'd put the static out of the function... for greater visibility.
Otherwise: Reviewed-by: Pavel
On Thu 2020-09-10 00:15:26, Marek Behun wrote:
> On Wed, 9 Sep 2020 23:40:09 +0200
> Pavel Machek wrote:
>
> > > >
> > > > 80 columns :-) (and please fix that globally, at least at places where
> > > > it is easy, like comments).
> > > >
Hi!
> > > Many an ethernet PHY (and other chips) supports various HW control modes
> > > for LEDs connected directly to them.
> >
> > I guess this should be
> >
> > "Many ethernet PHYs (and other chips) support various HW control modes
> > for LEDs connected directly to them."
> >
>
> I gues
Hi!
> Many an ethernet PHY (and other chips) supports various HW control modes
> for LEDs connected directly to them.
I guess this should be
"Many ethernet PHYs (and other chips) support various HW control modes
for LEDs connected directly to them."
> This API registers a new private LED trigge
Hi!
> > > The phydev name is not particularly nice:
> > >
> > > !mdio-mux!mdio@1!switch@0!mdio:00
...
> > > 400d.ethernet-1:00
> > > 400d.ethernet-1:01
> > > fixed-0:00
> >
> > Not nice, I see. In particular, it contains ":"... which would be a
> > problem.
> >
> > > The interface name
Hi!
> > > And no, I don't want phydev name there.
> >
> > Ummm. Can we get little more explanation on that? I fear that LED
> > device renaming will be tricky and phydev would work around that
> > nicely.
>
> Hi Pavel
>
> The phydev name is not particularly nice:
>
> !mdio-mux!mdio@1!switch@0!
On Fri 2020-08-07 14:29:09, Jonathan Adams wrote:
> [resending to widen the CC lists per rdun...@infradead.org's suggestion
> original posting to lkml here: https://lkml.org/lkml/2020/8/5/1009]
>
> To try to restart the discussion of kernel statistics started by the
> statsfs patchsets (https://lk
On Sat 2020-07-25 20:48:46, Andrew Lunn wrote:
> > > > +#if 0
> > > > + /* LED_COLOR_ID_MULTI is not yet merged in Linus' tree */
> > > > + /* TODO: Support DUAL MODE */
> > > > + if (color == LED_COLOR_ID_MULTI) {
> > > > + phydev_warn(phydev, "node %pOF: This drive
Hi!
> this is v4 of my RFC adding support for LEDs connected to Marvell PHYs.
>
> Please note that if you want to test this, you still need to first apply
> the patch adding the LED private triggers support from Pavel's tree.
> https://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds.git/
Hi!
> More about CAN related projects used and developed at the Faculty
> of the Electrical Engineering (http://www.fel.cvut.cz/en/)
> of Czech Technical University (https://www.cvut.cz/en)
> in at Prague http://canbus.pages.fel.cvut.cz/ .
Should this go to Documentation, not a changelog?
> +
On Tue 2020-08-04 11:18:17, Pavel Machek wrote:
> Hi!
>
> > The commit text again to make checkpatch happy.
>
> ?
>
>
> > +oneOf:
> > + - items:
> > + - const: ctu,ctucanfd
> > + - const: ctu,canfd-2
> > + -
Hi!
> The commit text again to make checkpatch happy.
?
> +oneOf:
> + - items:
> + - const: ctu,ctucanfd
> + - const: ctu,canfd-2
> + - const: ctu,ctucanfd
For consistency, can we have ctu,canfd-1, ctu,canfd-2?
Best regards,
Hi!
> > > My main issue though is whether one "hw-control" trigger should be
> > > registered via LED API and the specific mode should be chosen via
> > > another sysfs file as in this RFC, or whether each HW control mode
> > > should have its own trigger. The second solution would either result i
Hi!
> +static const struct marvell_led_mode_info marvell_led_mode_info[] = {
> + { "link", { 0x0, -1, 0x0, -1, -1, -1, }, 0 },
> + { "link/act", { 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, }, 0 },
> + { "1Gbps/100Mbps/10Mbps", { 0x2, -1, -1, -1,
Hi!
> Many PHYs support various HW control modes for LEDs connected directly
> to them.
>
> This code adds a new private LED trigger called phydev-hw-mode. When
> this trigger is enabled for a LED, the various HW control modes which
> the PHY supports for given LED can be get/set via hw_mode sysf
On Fri 2020-07-24 15:12:33, Marek Behún wrote:
> On Fri, 24 Jul 2020 12:29:01 +0200
> Pavel Machek wrote:
>
> > In future, would you expect having software "1000/100/10/nolink"
> > triggers I could activate on my scrollock LED (or on GPIO controlled
> &g
Simplify error handling; we already know mwq is NULL.
Signed-off-by: Pavel Machek (CIP)
diff --git a/drivers/slimbus/qcom-ngd-ctrl.c b/drivers/slimbus/qcom-ngd-ctrl.c
index 743ee7b4e63f..3def0c782c7f 100644
--- a/drivers/slimbus/qcom-ngd-ctrl.c
+++ b/drivers/slimbus/qcom-ngd-ctrl.c
@@ -1396,17
On Thu 2020-07-23 20:13:18, Marek Behún wrote:
> Hi,
>
> this is v2 of my RFC adding support for LEDs connected to Marvell PHYs.
>
> The LED subsystem patches are not contained:
> - the patch adding support for LED private triggers is already accepted
> in Pavel Machek's for-next tree.
> If y
Hi!
> > I expect some of this should be moved into the phylib core. We don't
> > want each PHY inventing its own way to do this. The core should
> > provide a framework and the PHY driver fills in the gaps.
> >
> > Take a look at for example mscc_main.c and its LED information. It has
> > pretty
Typo "destoy" made me wonder if correct patch is wrong; fix it. No
functional change.
Signed-off-by: Pavel Machek (CIP)
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c
b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 4ed21dad6a8e..1bb55b9532c9 100644
--- a/drivers/net/wireless
Hi!
> > +{
> > + struct phy_device *phydev = to_phy_device(cdev->dev->parent);
> > + struct marvell_phy_led *led = to_marvell_phy_led(cdev);
> > + u8 val;
> > +
> > + /* don't do anything if HW control is enabled */
> > + if (check_trigger && cdev->trigger == &marvell_hw_led_trigger)
> >
Hi!
> >This adds support for registering such triggers.
> >
> >This code is based on work by Pavel Machek and
> >Ondřej Jirman .
> >
> >Signed-off-by: Marek Behún
> Acked-by: Jacek Anaszewski
Thanks, applied.
s adds support for registering such triggers.
>
> This code is based on work by Pavel Machek and
> Ondřej Jirman .
>
> Signed-off-by: Marek Behún
Looks good to me. I'll likely apply it soon...
Best regards,
Hi!
> Currently when the .activate() method fails and returns a negative error
> code while writing to the /sys/class/leds//trigger file, the write
> system call does not inform the user abouth this failure.
>
> This patch fixes this.
>
> Signed-off-by: Marek Behún
> ---
> drivers/leds/led-tri
On Tue 2020-07-07 17:38:46, Marcel Holtmann wrote:
> Hi Miao-chen,
>
> > This fixes the kernel oops by removing unnecessary background scan
> > update from hci_adv_monitors_clear() which shouldn't invoke any work
> > queue.
> >
> > The following test was performed.
> > - Run "rmmod btusb" and ver
64bit division is kind of expensive, and shift should do the job here.
Signed-off-by: Pavel Machek (CIP)
---
Now with patch. Sorry about that.
diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
index 3889bd9aec46..d6c91a43a1ee 100644
--- a/net/xdp/xdp_umem.c
+++ b/net/xdp/xdp_umem.c
Doing mod_timer() conditionaly is easier than conditionally unlocking
and jumping around...
Signed-off-by: Pavel Machek (CIP)
diff --git a/net/mac80211/mesh_hwmp.c b/net/mac80211/mesh_hwmp.c
index aa5150929996..02cde0fd08fe 100644
--- a/net/mac80211/mesh_hwmp.c
+++ b/net/mac80211/mesh_hwmp.c
64bit division is kind of expensive, and shift should do the job here.
Signed-off-by: Pavel Machek (CIP)
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
signature.asc
Description: Digital signature
Hi!
> From: Roman Mashak
>
> [ Upstream commit b15e62631c5f19fea9895f7632dae9c1b27fe0cd ]
>
> When a new action is installed, firstuse field of 'tcf_t' is explicitly set
> to 0. Value of zero means "new action, not yet used"; as a packet hits the
> action, 'firstuse' is stamped with the current
On Tue 2020-05-26 10:37:36, Rafael J. Wysocki wrote:
> On Mon, May 25, 2020 at 8:26 PM Krzysztof Wilczyński wrote:
> >
> > Use the new device_to_pm() helper to access Power Management callbacs
> > (struct dev_pm_ops) for a particular device (struct device_driver).
> >
> > No functional change inte
On Mon 2020-05-25 15:57:28, Andrew Lunn wrote:
> > > standardizing on rx-delay-ps and tx-delay-ps would make sense since that
> > > is the lowest resolution and the property would be correctly named with
> > > an unit in the name.
> >
> > Seems like similar patch is already being reviewed from Dan
Hi!
> > On Tue 2020-05-12 23:10:56, Martin Blumenstingl wrote:
> >> The PRG_ETHERNET registers on Meson8b and newer SoCs can add an RX
> >> delay. Add a property with the known supported values so it can be
> >> configured according to the board layout.
> >>
> >> Reviewed-by: Andrew Lunn
> >> Sig
Hi!
>
> If the feedback from the community is truly and finally that system() should
> not be used in these applications, then is there support for updating the man
> page to better communicate that?
>
Clarifying documenation might be the best way forward. Note you'd have
to do that anyway, s
On Tue 2020-05-12 23:10:56, Martin Blumenstingl wrote:
> The PRG_ETHERNET registers on Meson8b and newer SoCs can add an RX
> delay. Add a property with the known supported values so it can be
> configured according to the board layout.
>
> Reviewed-by: Andrew Lunn
> Signed-off-by: Martin Blumens
On Tue 2020-05-12 15:04:18, Andrew Lunn wrote:
> > > As for getting / setting the threshold, perhaps ETHTOOL_MSG_LINKINFO_GET
> > > and ETHTOOL_MSG_LINKINFO_SET. Unless you expect more configurable
> > > parameters like this in which case we may want to consider adding new
> > > request type (e.g.
> > The SNR seems to be most universal value, when it comes to comparing
> > different situations (different links and different PHYs). The
> > resolution of BER is not that detailed, for the NXP PHY is says only
> > "BER below 1e-10" or not.
>
> The point I was trying to make is that SQI is inten
On Wed 2019-02-20 15:49:25, Joe Perches wrote:
> On Tue, 2019-02-12 at 19:51 -0800, Florian Fainelli wrote:
> > On February 12, 2019 6:39:49 PM PST, tristram...@microchip.com wrote:
> > > > > +static void ksz9477_freeze_mib(struct ksz_device *dev, int port,
> > > > > + b
then removed from the driver, and then
> from DSA as a whole.
>
> This is compile tested only. Comment and testing welcome.
Series looks good to me. But I have out of tree board 6065, not 6060,
so testing is not too easy.
P
On Wed 2019-01-30 01:37:51, Andrew Lunn wrote:
> The REG_WRITE macro contains a return statement, making it not very
> safe. Remove it by inlining the code.
Not bad, but maybe there should be dev_err() or something in case of
reg_write() returns an error?
Because no errors are expected in this ca
of registers that are common to all
and that are newer-generations-only be? Mark everything not present on
6065 as MV88E6085_*?
Is someone is interested in getting 6060 to work with mv88e6xxx?
Best regards,
Pavel
comm
On Fri 2019-01-18 20:32:17, tristram...@microchip.com wrote:
> > > These extremely patches look similar to what I posted here before:
> > >
> > > https://patchwork.ozlabs.org/cover/1017222/
> > >
> > > But the authorship has changed. Why ?
> >
> > There seems to be explanation in 0/4.
> >
> > Tri
On Fri 2019-01-18 07:29:35, Marek Vasut wrote:
> On 1/17/19 4:22 AM, tristram...@microchip.com wrote:
> > From: Tristram Ha
> >
> > Convert KSZ9477 SPI driver to use regmap mechanism so that an I2C driver
> > can be easily added.
> >
> > KSZ9477 SPI driver uses a 32-bit SPI command containing a
On Wed 2018-12-19 22:50:16, tristram...@microchip.com wrote:
> > This header file makes no sense. Please move the functions into .c
> > >>>
> > >>> No, that would make code bigger & slower.
> > >>>
> > >>> It makes sense to me. But I'd add "inline" keyword to make the goal
> > >>> explicit.
>
On Thu 2018-12-06 13:28:56, Vokáč Michal wrote:
> On 6.12.2018 14:05, Pavel Machek wrote:
> >
> > Fix typo and fix compatible value that is not actually permitted by the
> > description in the example.
>
> Ahoj Pavle, I think the subject should be more like:
&
On Fri 2018-11-30 21:58:36, Anderson Luiz Alves wrote:
> Disable hardware level MAC learning because it breaks station roaming.
> When enabled it drops all frames that arrive from a MAC address
> that is on a different port at learning table.
>
> Signed-off-by: Anderson Luiz Alves
Will not this
On Wed 2018-12-19 17:15:32, Jiri Pirko wrote:
> Wed, Dec 19, 2018 at 05:08:57PM CET, pa...@denx.de wrote:
> >Hi!
> >
> >> >+static int ksz_i2c_write32(struct ksz_device *dev, u32 reg, u32 value)
> >> >+{
> >> >+ value = cpu_to_be32(value);
> >> >+ return ksz_i2c_write(dev, reg, &value, 4);
> >> >+}
Hi!
> >+static int ksz_i2c_write32(struct ksz_device *dev, u32 reg, u32 value)
> >+{
> >+value = cpu_to_be32(value);
> >+return ksz_i2c_write(dev, reg, &value, 4);
> >+}
> >+
> >+static int ksz_i2c_get(struct ksz_device *dev, u32 reg, void *data, size_t
> >len)
> >+{
> >+return ksz_i2
On Mon 2018-12-03 10:45:01, Kalle Valo wrote:
> Pavel Machek writes:
>
> > While grepping something else, I came across LED trigger that is named
> > just "tx".
> >
> > That's a bit too generic afaict?
> >
> > +++ b/drivers/net/wireles
On Thu 2018-12-06 20:00:26, tristram...@microchip.com wrote:
> > >>> Update tag_ksz.c to access switch driver's tail tagging operations.
> > >>
> > >> Hi Tristram
> > >>
> > >> Humm, i'm not sure we want this, the tagging spit into two places. I
> > >> need to take a closer look at the previous pa
On Thu 2018-12-06 12:21:59, David Miller wrote:
>
> Plain "printk" are never appropriate.
>
> Please explicitly use pr_warn() or similar. If there is a device context
> available, either a generic device or a netdev, use one of the dev_*()
> or netdev_*() variants.
Can do, I guess is there'
On Thu 2018-12-06 12:23:33, David Miller wrote:
> From: Pavel Machek
> Date: Thu, 6 Dec 2018 14:03:45 +0100
>
> > @@ -79,7 +82,7 @@ static enum dsa_tag_protocol
> > mv88e6060_get_tag_protocol(struct dsa_switch *ds,
> > {
> >//return DSA_TAG_PROTO_QCA;
>
Hi!
> >>> 6065 indeed has some kind of "egress tagging mode" (with four
> >>> options), but I have trouble understanding what it really does.
> >>
> >> What are the options?
> >
> > "transmit unmodified", "transmit untagged", "transmit tagged" and
> > "transmit all frames double tagged".
>
> It
Tagging scheme used by 88e6065 is "interesting" as it moves around
ethernet addreses and forces us to use PROMISC mode on the ethernets.
I'm not sure how to call it, so I selected tag_daddr ("tag where
destination address should be").
Signed-off-by: Pavel Machek
diff
Fix typo and fix compatible value that is not actually permitted by the
description in the example.
Signed-off-by: Pavel Machek
diff --git a/Documentation/devicetree/bindings/net/dsa/marvell.txt
b/Documentation/devicetree/bindings/net/dsa/marvell.txt
index feb007af13cb..abf1be036ac5
This is NOT ready for merge, as you lose support for 6060. Probably
not what you want.
Signed-off-by: Pavel Machek (not ready)
diff --git a/drivers/net/dsa/mv88e6060.c b/drivers/net/dsa/mv88e6060.c
index 9e3901f18518..9c9b4792bbad 100644
--- a/drivers/net/dsa/mv88e6060.c
+++ b/drivers
mv88e6060: Allow the driver to be probed from device tree
This is NOT ready for merge. Hardcoding an address is a bad idea, and obviously
it would be good to allow module removal, too.
Signed-off-by: Pavel Machek (not ready)
diff --git a/drivers/net/dsa/mv88e6060.c b/drivers/net/dsa
Errors communicating with the chip are not expected, warn about them.
Signed-off-by: Pavel Machek
diff --git a/drivers/net/dsa/mv88e6060.c b/drivers/net/dsa/mv88e6060.c
index 65f10fec25b3..f43104f48dbb 100644
--- a/drivers/net/dsa/mv88e6060.c
+++ b/drivers/net/dsa/mv88e6060.c
@@ -30,8
Hi!
> I'm trying to create support for Marvell 88e6065 switch... and it
> seems like drivers/net/dsa supports everything, but this model.
I have something that works, but is far from suitable for
mainline. Few parts are good, those will be marked PATCH, rest will be
RFD. I'm not sure how much wor
Hi!
> > > > But I'm running into problems with tagging code, and I guess I'd like
> > > > some help understanding.
> > > >
> > > > tag_trailer: allocates new skb, then copies data around.
> > > >
> > > > tag_qca: does dev->stats.tx_packets++, and reuses existing skb.
> > > >
> > > > tag_brcm: r
1 - 100 of 403 matches
Mail list logo
