Re: [RESEND v2] iommu/vt-d: Use passthrough mode for the Intel IPUs

On Tue, Apr 20, 2021 at 11:02 AM Sakari Ailus wrote: > > Hi Bingbu, > > Thanks for the patch. > > On Tue, Apr 20, 2021 at 10:48:33AM +0800, Bingbu Cao wrote: > > Intel IPU(Image Processing Unit) has its own (IO)MMU hardware, > > The IPU driver allocates its own page table that is not mapped > >

Re: [PATCH net-next v4 0/4] usbnet: speed reporting for devices without MDIO

[Key part of Andew's reply: "Yes, this discussion should not prevent this patchset from being merged."] On Tue, Apr 6, 2021 at 1:00 PM Andrew Lunn wrote: > > > > Speed: 2500Mb/s and Duplex: Half is very unlikely. You really only > > > ever see 10 Half and occasionally 100 Half. Anything above

Re: [PATCH net-next v4 0/4] usbnet: speed reporting for devices without MDIO

On Tue, Apr 6, 2021 at 12:09 AM Andrew Lunn wrote: > > On Mon, Apr 05, 2021 at 04:13:40PM -0700, Grant Grundler wrote: > > This series introduces support for USB network devices that report > > speed as a part of their protocol, not emulating an MII to be accessed > &g

Re: [PATCHv4 0/4] usbnet: speed reporting for devices without MDIO

On Tue, Mar 30, 2021 at 2:17 AM Grant Grundler wrote: > > This series introduces support for USB network devices that report > speed as a part of their protocol, not emulating an MII to be accessed > over MDIO. > > v2: rebased on recent upstream changes > v3: incorpo

[PATCH net-next v4 3/4] net: cdc_ncm: record speed in status method

replaces the one recently submitted in de658a195ee23ca6aaffe197d1d2ea040beea0a2 : "net: usb: cdc_ncm: don't spew notifications" v2: rebased on upstream v3: changed variable names v4: rewrote commit message Signed-off-by: Oliver Neukum Tested-by: Roland Dreier Signed-off-by: Gran

[PATCH net-next v4 4/4] net: cdc_ether: record speed in status method

framework to use the new functions to get link speed/state. User space can now get the most recent link speed/state using ethtool. v4: added to series since cdc_ether uses same notifications as cdc_ncm driver. Signed-off-by: Grant Grundler Reviewed-by: Andrew Lunn --- drivers/net/usb

[PATCH net-next v4 2/4] usbnet: add method for reporting speed without MII

on upstream v3: changed names and made clear which units are used v4: moved hunks to correct patch; rewrote commmit messages Signed-off-by: Oliver Neukum Tested-by: Roland Dreier Reviewed-by: Grant Grundler Tested-by: Grant Grundler Reviewed-by: Andrew Lunn --- drivers/net/usb/usbnet.c | 23

[PATCH net-next v4 1/4] usbnet: add _mii suffix to usbnet_set/get_link_ksettings

rename the existing functions with _mii suffix. v2: rebased on changed upstream v3: changed names to clearly say that this does NOT use phylib v4: moved hunks to correct patch; reworded commmit messages Signed-off-by : Oliver Neukum Tested-by: Roland Dreier Reviewed-by: Grant Grundler Tested

[PATCH net-next v4 0/4] usbnet: speed reporting for devices without MDIO

This series introduces support for USB network devices that report speed as a part of their protocol, not emulating an MII to be accessed over MDIO. v2: rebased on recent upstream changes v3: incorporated hints on naming and comments v4: fix misplaced hunks; reword some commit messages; add

[PATCHv4 3/4] net: cdc_ncm: record speed in status method

replaces the one recently submitted in de658a195ee23ca6aaffe197d1d2ea040beea0a2 : "net: usb: cdc_ncm: don't spew notifications" v2: rebased on upstream v3: changed variable names v4: rewrote commit message Signed-off-by: Oliver Neukum Tested-by: Roland Dreier Signed-off-by: Gran

[PATCHv4 4/4] net: cdc_ether: record speed in status method

From: Grant Grundler Until very recently, the usbnet framework only had support functions for devices which reported the link speed by explicitly querying the PHY over a MDIO interface. However, the cdc_ether devices send notifications when the link state or link speeds change and do not expose

[PATCHv4 2/4] usbnet: add method for reporting speed without MII

on upstream v3: changed names and made clear which units are used v4: moved hunks to correct patch; rewrote commmit messages Signed-off-by: Oliver Neukum Tested-by: Roland Dreier Reviewed-by: Grant Grundler Tested-by: Grant Grundler --- drivers/net/usb/usbnet.c | 23

[PATCHv4 1/4] usbnet: add _mii suffix to usbnet_set/get_link_ksettings

rename the existing functions with _mii suffix. v2: rebased on changed upstream v3: changed names to clearly say that this does NOT use phylib v4: moved hunks to correct patch; reworded commmit messages Signed-off-by : Oliver Neukum Tested-by: Roland Dreier Reviewed-by: Grant Grundler Tested

[PATCHv4 0/4] usbnet: speed reporting for devices without MDIO

This series introduces support for USB network devices that report speed as a part of their protocol, not emulating an MII to be accessed over MDIO. v2: rebased on recent upstream changes v3: incorporated hints on naming and comments v4: fix misplaced hunks; reword some commit messages; add

[PATCH net-next] net: usb: log errors to dmesg/syslog

Errors in protocol should be logged when the driver aborts operations. If the driver can carry on and "humor" the device, then emitting the message as debug output level is fine. Signed-off-by: Grant Grundler --- drivers/net/usb/usbnet.c | 2 +- 1 file changed, 1 insertion(+),

[PATCH net-next] net: usb: cdc_ncm: emit dev_err on error paths

Several error paths in bind/probe code will only emit output using dev_dbg. But if we are going to fail the bind/probe, emit related output with "err" priority. Signed-off-by: Grant Grundler --- drivers/net/usb/cdc_ncm.c | 10 +- 1 file changed, 5 insertions(+), 5

Re: [PATCH net] net: usb: cdc_ncm: don't spew notifications

On Wed, Jan 20, 2021 at 5:04 PM Jakub Kicinski wrote: > > On Wed, 20 Jan 2021 03:38:32 + Hayes Wang wrote: > > Grant Grundler > > > Sent: Wednesday, January 20, 2021 9:12 AM > > > Subject: [PATCH net] net: usb: cdc_ncm: don't spew notifications > > >

Re: [PATCH 3/3] net: usb: cdc_ncm: don't spew notifications

On Wed, Jan 20, 2021 at 1:05 AM Jakub Kicinski wrote: > > On Wed, 20 Jan 2021 00:59:17 + Grant Grundler wrote: > > > > Thanks for the patch, this looks like an improvement over: > > > > > > > > 59b4a8fa27f5 ("CDC-NCM: remove "connected&q

[PATCH net] net: usb: cdc_ncm: don't spew notifications

ink ... Chrome OS cannot support RTL8156 until this is fixed. Signed-off-by: Grant Grundler --- drivers/net/usb/cdc_ncm.c | 12 +++- include/linux/usb/usbnet.h | 2 ++ 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c in

Re: [PATCH 3/3] net: usb: cdc_ncm: don't spew notifications

On Wed, Jan 20, 2021 at 12:55 AM Grant Grundler wrote: > > On Tue, Jan 19, 2021 at 9:46 PM Jakub Kicinski wrote: > > > > On Fri, 15 Jan 2021 21:26:23 -0800 Grant Grundler wrote: > > > RTL8156 sends notifications about every 32ms. > > > Only display/log

Re: [PATCH 3/3] net: usb: cdc_ncm: don't spew notifications

On Tue, Jan 19, 2021 at 9:46 PM Jakub Kicinski wrote: > > On Fri, 15 Jan 2021 21:26:23 -0800 Grant Grundler wrote: > > RTL8156 sends notifications about every 32ms. > > Only display/log notifications when something changes. > > > > This issue has been repor

Re: [PATCH 3/3] net: usb: cdc_ncm: don't spew notifications

+nic_swsd [adding per Realtek developer team request] On Sat, Jan 16, 2021 at 5:27 AM Grant Grundler wrote: > > RTL8156 sends notifications about every 32ms. > Only display/log notifications when something changes. > > This issue has been reported by others: > https://

Re: [PATCH 2/3] net: usb: log errors to dmesg/syslog

+nic_swsd [adding per Realtek developer team request] On Sat, Jan 16, 2021 at 5:27 AM Grant Grundler wrote: > > Errors in protocol should be logged when the driver aborts operations. > If the driver can carry on and "humor" the device, then emitting > the message as debu

Re: [PATCH 1/3] net: usb: cdc_ncm: emit dev_err on error paths

+nic_swsd [adding per Realtek developer team request] On Sat, Jan 16, 2021 at 5:26 AM Grant Grundler wrote: > > Several error paths in bind/probe code will only emit > output using dev_dbg. But if we are going to fail the > bind/probe, emit related output with "err" pr

[PATCH 1/3] net: usb: cdc_ncm: emit dev_err on error paths

Several error paths in bind/probe code will only emit output using dev_dbg. But if we are going to fail the bind/probe, emit related output with "err" priority. Signed-off-by: Grant Grundler --- drivers/net/usb/cdc_ncm.c | 10 +- 1 file changed, 5 insertions(+), 5 deletion

[PATCH 3/3] net: usb: cdc_ncm: don't spew notifications

ink ... Chrome OS cannot support RTL8156 until this is fixed. Signed-off-by: Grant Grundler --- drivers/net/usb/cdc_ncm.c | 12 +++- include/linux/usb/usbnet.h | 2 ++ 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c in

[PATCH 2/3] net: usb: log errors to dmesg/syslog

Errors in protocol should be logged when the driver aborts operations. If the driver can carry on and "humor" the device, then emitting the message as debug output level is fine. Signed-off-by: Grant Grundler --- drivers/net/usb/usbnet.c | 2 +- 1 file changed, 1 insertion(+),

Re: Apply from 2018? [V2,0/3] phy: qcom-ipq4019-usb: add new driver

Adding linux-...@vger.kernel.org since Andy's email in MAINTAINERs bounced. Using Matthew's personal email since his codeaurora email bounced. On Mon, Sep 7, 2020 at 11:35 PM Grant Grundler wrote: > > Alban, Andy, > Can you please apply this patch series from 2018 or please explain

Apply from 2018? [V2,0/3] phy: qcom-ipq4019-usb: add new driver

-documen.patch ... In 2018, Rob Herring reviewed (and approved): [V2,1/3] dt-bindings: phy-qcom-ipq4019-usb: add binding document I've just reviewed 2/3 and 3/3. You can add to those: Reviewed-by: Grant Grundler I compared 3/3 with the DTS entries that were submitted (and I approved) to chromeos

Re: [PATCH V2] ASoC: max98373: Added max98373_reset for stable amp reset

On Wed, Nov 28, 2018 at 9:07 AM Ryan Lee wrote: > > >-Original Message- > >From: Mark Brown > >Sent: Wednesday, November 28, 2018 1:50 AM > >To: Ryan Lee > >Cc: Liam Girdwood ; Jaroslav Kysela > >; Takashi Iwai ; Grant Grundler > >; Kun

Re: [PATCH V2] ASoC: max98373: Added max98373_reset for stable amp reset

On Wed, Nov 28, 2018 at 9:07 AM Ryan Lee wrote: > > >-Original Message- > >From: Mark Brown > >Sent: Wednesday, November 28, 2018 1:50 AM > >To: Ryan Lee > >Cc: Liam Girdwood ; Jaroslav Kysela > >; Takashi Iwai ; Grant Grundler > >; Kun

Re: [PATCH] ASoC: max98373: Added max98373_reset for stable amp reset

I just realized I had one more question... On Mon, Nov 26, 2018 at 6:24 PM Grant Grundler wrote: > > Hi Ryan! > > Just some questions inline - in general I like the reset function. > > On Mon, Nov 26, 2018 at 10:46 AM Ryan Lee > wrote: > > > > Signed-off-b

Re: [PATCH] ASoC: max98373: Added max98373_reset for stable amp reset

I just realized I had one more question... On Mon, Nov 26, 2018 at 6:24 PM Grant Grundler wrote: > > Hi Ryan! > > Just some questions inline - in general I like the reset function. > > On Mon, Nov 26, 2018 at 10:46 AM Ryan Lee > wrote: > > > > Signed-off-b

Re: [PATCH] ASoC: max98373: Added max98373_reset for stable amp reset

Hi Ryan! Just some questions inline - in general I like the reset function. On Mon, Nov 26, 2018 at 10:46 AM Ryan Lee wrote: > > Signed-off-by: Ryan Lee > --- > Changes : Created max98373_reset function to minimize code duplication. >Changed regmap_write to regmap_update_bits.

Re: [PATCH] ASoC: max98373: Added max98373_reset for stable amp reset

Hi Ryan! Just some questions inline - in general I like the reset function. On Mon, Nov 26, 2018 at 10:46 AM Ryan Lee wrote: > > Signed-off-by: Ryan Lee > --- > Changes : Created max98373_reset function to minimize code duplication. >Changed regmap_write to regmap_update_bits.

Re: [PATCH] ASoC: max98373: usleep_range() needs include/delay.h

On Fri, Sep 7, 2018 at 10:56 AM Mark Brown wrote: > > On Fri, Sep 07, 2018 at 10:52:24AM -0700, Grant Grundler wrote: > > On Fri, Sep 7, 2018 at 5:11 AM Mark Brown wrote: > > > > Note that this isn't causing a warning upstream, presumably due to an > > > impl

Re: [PATCH] ASoC: max98373: usleep_range() needs include/delay.h

On Fri, Sep 7, 2018 at 10:56 AM Mark Brown wrote: > > On Fri, Sep 07, 2018 at 10:52:24AM -0700, Grant Grundler wrote: > > On Fri, Sep 7, 2018 at 5:11 AM Mark Brown wrote: > > > > Note that this isn't causing a warning upstream, presumably due to an > > > impl

Re: [PATCH] ASoC: max98373: usleep_range() needs include/delay.h

[resending as plain/text - sorry] On Fri, Sep 7, 2018 at 10:52 AM Grant Grundler wrote: > > > > On Fri, Sep 7, 2018 at 5:11 AM Mark Brown wrote: >> >> On Thu, Sep 06, 2018 at 05:27:28PM -0700, Grant Grundler wrote: >> > Commit ca917f9f

Re: [PATCH] ASoC: max98373: usleep_range() needs include/delay.h

[resending as plain/text - sorry] On Fri, Sep 7, 2018 at 10:52 AM Grant Grundler wrote: > > > > On Fri, Sep 7, 2018 at 5:11 AM Mark Brown wrote: >> >> On Thu, Sep 06, 2018 at 05:27:28PM -0700, Grant Grundler wrote: >> > Commit ca917f9f

[PATCH] ASoC: max98373: usleep_range() needs include/delay.h

f function 'usleep_range' [-Werror,-Wimplicit-function-declaration] usleep_range(1, 11000); ^ Including delay.h "fixes" this. Signed-off-by: Grant Grundler --- sound/soc/codecs/max98373.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/codecs/max98373.

[PATCH] ASoC: max98373: usleep_range() needs include/delay.h

f function 'usleep_range' [-Werror,-Wimplicit-function-declaration] usleep_range(1, 11000); ^ Including delay.h "fixes" this. Signed-off-by: Grant Grundler --- sound/soc/codecs/max98373.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/codecs/max98373.

Re: [PATCH stable v4.4+] r8152: add Linksys USB3GIGV1 id

On Thu, Apr 26, 2018 at 12:56 AM, Krzysztof Kozlowski <k...@kernel.org> wrote: > On Thu, Apr 26, 2018 at 2:40 AM, Grant Grundler <grund...@chromium.org> wrote: >> On Wed, Apr 25, 2018 at 2:54 AM, Krzysztof Kozlowski <k...@kernel.org&g

Re: [PATCH stable v4.4+] r8152: add Linksys USB3GIGV1 id

On Thu, Apr 26, 2018 at 12:56 AM, Krzysztof Kozlowski wrote: > On Thu, Apr 26, 2018 at 2:40 AM, Grant Grundler wrote: >> On Wed, Apr 25, 2018 at 2:54 AM, Krzysztof Kozlowski >> wrote: >>> >>> commit 90841047a01b452cc8c3f9b990698b264143334a upstream >>>

Re: [PATCH stable v4.4+] r8152: add Linksys USB3GIGV1 id

ID 13b1:0041 Linksys > > Signed-off-by: Grant Grundler <grund...@chromium.org> > Reviewed-by: Douglas Anderson <diand...@chromium.org> > Signed-off-by: David S. Miller <da...@davemloft.net> > [krzk: Rebase on v4.4] > Signed-off-by: Krzysztof Kozlowski <k...@kerne

Re: [PATCH stable v4.4+] r8152: add Linksys USB3GIGV1 id

> > Signed-off-by: Grant Grundler > Reviewed-by: Douglas Anderson > Signed-off-by: David S. Miller > [krzk: Rebase on v4.4] > Signed-off-by: Krzysztof Kozlowski thanks krzk! FTR, to support RTL8153B (HW ID 0x6010), the follow patch series to bring r8152 v1.09.9 driver from 4.14 ke

Re: [PATCH V4] r8152: add Linksys USB3GIGV1 id

On Sun, Oct 1, 2017 at 10:39 PM, David Miller <da...@davemloft.net> wrote: > From: Grant Grundler <grund...@chromium.org> > Date: Thu, 28 Sep 2017 11:35:00 -0700 > >> This linksys dongle by default comes up in cdc_ether mode. >> This patch allows r8152 to claim the

Re: [PATCH V4] r8152: add Linksys USB3GIGV1 id

On Sun, Oct 1, 2017 at 10:39 PM, David Miller wrote: > From: Grant Grundler > Date: Thu, 28 Sep 2017 11:35:00 -0700 > >> This linksys dongle by default comes up in cdc_ether mode. >> This patch allows r8152 to claim the device: >>Bus 002 Device 002: ID 13b1:00

[PATCH V4] r8152: add Linksys USB3GIGV1 id

This linksys dongle by default comes up in cdc_ether mode. This patch allows r8152 to claim the device: Bus 002 Device 002: ID 13b1:0041 Linksys Signed-off-by: Grant Grundler <grund...@chromium.org> --- drivers/net/usb/cdc_ether.c | 10 ++ drivers/net/usb/r8152.c | 2 ++ 2

[PATCH V4] r8152: add Linksys USB3GIGV1 id

This linksys dongle by default comes up in cdc_ether mode. This patch allows r8152 to claim the device: Bus 002 Device 002: ID 13b1:0041 Linksys Signed-off-by: Grant Grundler --- drivers/net/usb/cdc_ether.c | 10 ++ drivers/net/usb/r8152.c | 2 ++ 2 files changed, 12 insertions

Re: [PATCH V3] r8152: add Linksys USB3GIGV1 id

Hi Doug! On Wed, Sep 27, 2017 at 4:47 PM, Doug Anderson <diand...@chromium.org> wrote: > Hi, > > On Wed, Sep 27, 2017 at 10:28 AM, Grant Grundler <grund...@chromium.org> > wrote: >> This linksys dongle by default comes up in cdc_ether mode. >> This pa

Re: [PATCH V3] r8152: add Linksys USB3GIGV1 id

Hi Doug! On Wed, Sep 27, 2017 at 4:47 PM, Doug Anderson wrote: > Hi, > > On Wed, Sep 27, 2017 at 10:28 AM, Grant Grundler > wrote: >> This linksys dongle by default comes up in cdc_ether mode. >> This patch allows r8152 to claim the device: >>Bus 002 De

[PATCH V3] r8152: add Linksys USB3GIGV1 id

This linksys dongle by default comes up in cdc_ether mode. This patch allows r8152 to claim the device: Bus 002 Device 002: ID 13b1:0041 Linksys Signed-off-by: Grant Grundler <grund...@chromium.org> --- drivers/net/usb/cdc_ether.c | 10 ++ drivers/net/usb/r8152.c | 2 ++ 2

[PATCH V3] r8152: add Linksys USB3GIGV1 id

This linksys dongle by default comes up in cdc_ether mode. This patch allows r8152 to claim the device: Bus 002 Device 002: ID 13b1:0041 Linksys Signed-off-by: Grant Grundler --- drivers/net/usb/cdc_ether.c | 10 ++ drivers/net/usb/r8152.c | 2 ++ 2 files changed, 12 insertions

Re: [PATCH V2] r8152: add Linksys USB3GIGV1 id

On Wed, Sep 27, 2017 at 12:15 AM, Oliver Neukum wrote: > Am Dienstag, den 26.09.2017, 08:19 -0700 schrieb Doug Anderson: >> >> I know that for at least some of the adapters in the CDC Ethernet >> blacklist it was claimed that the CDC Ethernet support in the adapter >> was kinda

Re: [PATCH V2] r8152: add Linksys USB3GIGV1 id

On Wed, Sep 27, 2017 at 12:15 AM, Oliver Neukum wrote: > Am Dienstag, den 26.09.2017, 08:19 -0700 schrieb Doug Anderson: >> >> I know that for at least some of the adapters in the CDC Ethernet >> blacklist it was claimed that the CDC Ethernet support in the adapter >> was kinda broken anyway so

Re: [PATCH] r8152: add Linksys USB3GIGV1 id

On Mon, Sep 25, 2017 at 1:17 PM, Grant Grundler <grund...@chromium.org> wrote: ... > I didn't realize cdc_ether has a blacklist to make sure > RTL8152|RTL8153 devices are not picked up by cdc_ether. Would you > prefer I add this device to the blacklist in the same patch? I've sent

Re: [PATCH] r8152: add Linksys USB3GIGV1 id

On Mon, Sep 25, 2017 at 1:17 PM, Grant Grundler wrote: ... > I didn't realize cdc_ether has a blacklist to make sure > RTL8152|RTL8153 devices are not picked up by cdc_ether. Would you > prefer I add this device to the blacklist in the same patch? I've sent a V2 which also updates the

[PATCH V2] r8152: add Linksys USB3GIGV1 id

This linksys dongle by default comes up in cdc_ether mode. This patch allows r8152 to claim the device: Bus 002 Device 002: ID 13b1:0041 Linksys Signed-off-by: Grant Grundler <grund...@chromium.org> --- drivers/net/usb/cdc_ether.c | 8 drivers/net/usb/r8152.c | 2 ++ 2

[PATCH V2] r8152: add Linksys USB3GIGV1 id

This linksys dongle by default comes up in cdc_ether mode. This patch allows r8152 to claim the device: Bus 002 Device 002: ID 13b1:0041 Linksys Signed-off-by: Grant Grundler --- drivers/net/usb/cdc_ether.c | 8 drivers/net/usb/r8152.c | 2 ++ 2 files changed, 10 insertions

Re: [PATCH] r8152: add Linksys USB3GIGV1 id

[grrhmail...sorry! resending as plain text] Hallo Oliver! On Mon, Sep 25, 2017 at 7:51 AM, Oliver Neukum <oneu...@suse.com> wrote: > Am Freitag, den 22.09.2017, 12:06 -0700 schrieb Grant Grundler: > > This Linksys dongle by default comes up in cdc_ether mode. > > This patch

Re: [PATCH] r8152: add Linksys USB3GIGV1 id

[grrhmail...sorry! resending as plain text] Hallo Oliver! On Mon, Sep 25, 2017 at 7:51 AM, Oliver Neukum wrote: > Am Freitag, den 22.09.2017, 12:06 -0700 schrieb Grant Grundler: > > This Linksys dongle by default comes up in cdc_ether mode. > > This patch allows r8152 to c

[PATCH] r8152: add Linksys USB3GIGV1 id

This Linksys dongle by default comes up in cdc_ether mode. This patch allows r8152 to claim the device: Bus 002 Device 002: ID 13b1:0041 Linksys Signed-off-by: Grant Grundler <grund...@chromium.org> --- drivers/net/usb/r8152.c | 2 ++ 1 file changed, 2 insertions(+) This was

[PATCH] r8152: add Linksys USB3GIGV1 id

This Linksys dongle by default comes up in cdc_ether mode. This patch allows r8152 to claim the device: Bus 002 Device 002: ID 13b1:0041 Linksys Signed-off-by: Grant Grundler --- drivers/net/usb/r8152.c | 2 ++ 1 file changed, 2 insertions(+) This was tested on chromeos-3.14, chromeos-3.18

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

On Fri, Jul 14, 2017 at 2:35 PM, Daniel Vetter <dan...@ffwll.ch> wrote: > On Fri, Jul 14, 2017 at 7:32 PM, Grant Grundler <grund...@chromium.org> wrote: >> On Fri, Jul 14, 2017 at 2:11 AM, Jani Nikula >> <jani.nik...@linux.intel.com> wrote: >>&g

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

On Fri, Jul 14, 2017 at 2:35 PM, Daniel Vetter wrote: > On Fri, Jul 14, 2017 at 7:32 PM, Grant Grundler wrote: >> On Fri, Jul 14, 2017 at 2:11 AM, Jani Nikula >> wrote: >>> On Thu, 13 Jul 2017, Stéphane Marchesin >>> wrote: >>>> So, if you

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

On Fri, Jul 14, 2017 at 2:11 AM, Jani Nikula wrote: > On Thu, 13 Jul 2017, Stéphane Marchesin wrote: >> So, if you think this is wrong, can you fix this warning in a way that >> you'd like? > > As I replied previously [1], with more

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

On Fri, Jul 14, 2017 at 2:11 AM, Jani Nikula wrote: > On Thu, 13 Jul 2017, Stéphane Marchesin wrote: >> So, if you think this is wrong, can you fix this warning in a way that >> you'd like? > > As I replied previously [1], with more background, fixing the warnings > properly, in a way that

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

On Fri, May 5, 2017 at 1:08 PM, Ville Syrjälä wrote: ... >> > I'm not convinced the patch is making things any better really. To >> > fix this really properly, I think we'd need to introduce a new enum >> > pch_transcoder and thus avoid the confusion of which type

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

On Fri, May 5, 2017 at 1:08 PM, Ville Syrjälä wrote: ... >> > I'm not convinced the patch is making things any better really. To >> > fix this really properly, I think we'd need to introduce a new enum >> > pch_transcoder and thus avoid the confusion of which type of >> > transcoder we're talking

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

On Fri, May 5, 2017 at 10:40 AM, Ville Syrjälä wrote: > On Fri, May 05, 2017 at 10:26:36AM -0700, Matthias Kaehlcke wrote: >> El Thu, Apr 20, 2017 at 02:56:05PM -0700 Matthias Kaehlcke ha dit: >> >> > In several instances the driver passes an 'enum pipe' value to a

Re: [Intel-gfx] [PATCH RESEND] drm/i915: Fix pipe/transcoder enum mismatches

On Fri, May 5, 2017 at 10:40 AM, Ville Syrjälä wrote: > On Fri, May 05, 2017 at 10:26:36AM -0700, Matthias Kaehlcke wrote: >> El Thu, Apr 20, 2017 at 02:56:05PM -0700 Matthias Kaehlcke ha dit: >> >> > In several instances the driver passes an 'enum pipe' value to a >> > function expecting an

Re: [PATCH v1] hpet: Make cmd parameter of hpet_ioctl_common() unsigned

On Thu, Mar 23, 2017 at 11:54 PM, Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote: > On Thu, Mar 23, 2017 at 02:47:39PM -0700, Grant Grundler wrote: >> On Tue, Mar 14, 2017 at 12:56 AM, Clemens Ladisch <clem...@ladisch.de> wrote: >> > Matthias Kaehlcke

Re: [PATCH v1] hpet: Make cmd parameter of hpet_ioctl_common() unsigned

On Thu, Mar 23, 2017 at 11:54 PM, Greg Kroah-Hartman wrote: > On Thu, Mar 23, 2017 at 02:47:39PM -0700, Grant Grundler wrote: >> On Tue, Mar 14, 2017 at 12:56 AM, Clemens Ladisch wrote: >> > Matthias Kaehlcke wrote: >> >> The value passed by the two callers of t

Re: [PATCH v1] hpet: Make cmd parameter of hpet_ioctl_common() unsigned

On Tue, Mar 14, 2017 at 12:56 AM, Clemens Ladisch wrote: > Matthias Kaehlcke wrote: >> The value passed by the two callers of the function is unsigned anyway. > > Indeed; and those are just simple wrappers. > >> Making the parameter unsigned fixes the following warning when

Re: [PATCH v1] hpet: Make cmd parameter of hpet_ioctl_common() unsigned

On Tue, Mar 14, 2017 at 12:56 AM, Clemens Ladisch wrote: > Matthias Kaehlcke wrote: >> The value passed by the two callers of the function is unsigned anyway. > > Indeed; and those are just simple wrappers. > >> Making the parameter unsigned fixes the following warning when building >> with

Re: [PATCH] jiffies.h: Declare jiffies and jiffies_64 with ____cacheline_aligned_in_smp

Ping? Any feedback on this patch? Is this in someone's queue for review? thanks, grant On Tue, Mar 14, 2017 at 12:40 PM, Matthias Kaehlcke wrote: > jiffies_64 is defined in kernel/time/timer.c with > cacheline_aligned_in_smp, > however this macro is not part of the

Re: [PATCH] jiffies.h: Declare jiffies and jiffies_64 with ____cacheline_aligned_in_smp

Ping? Any feedback on this patch? Is this in someone's queue for review? thanks, grant On Tue, Mar 14, 2017 at 12:40 PM, Matthias Kaehlcke wrote: > jiffies_64 is defined in kernel/time/timer.c with > cacheline_aligned_in_smp, > however this macro is not part of the declaration of jiffies

Re: [PATCH] selinux: Remove unnecessary check of array base in selinux_set_mapping()

On Thu, Mar 23, 2017 at 5:08 AM, Paul Moore <p...@paul-moore.com> wrote: > On Wed, Mar 22, 2017 at 8:28 PM, Grant Grundler <grund...@chromium.org> wrote: >> Ping? Any feedback on this patch? > > It's on my list of patches to review, patience please. No probl

Re: [PATCH] selinux: Remove unnecessary check of array base in selinux_set_mapping()

On Thu, Mar 23, 2017 at 5:08 AM, Paul Moore wrote: > On Wed, Mar 22, 2017 at 8:28 PM, Grant Grundler wrote: >> Ping? Any feedback on this patch? > > It's on my list of patches to review, patience please. No problem! Thank you! just wanted confirmation it wasn't overlooked.

Re: [PATCH] selinux: Remove unnecessary check of array base in selinux_set_mapping()

[resending as plain text only - sorry] Ping? Any feedback on this patch? LGTM. cheers, grant On Thu, Mar 16, 2017 at 3:26 PM, Matthias Kaehlcke wrote: > 'perms' will never be NULL since it isn't a plain pointer but an array > of u32 values. > > This fixes the following

Re: [PATCH] selinux: Remove unnecessary check of array base in selinux_set_mapping()

[resending as plain text only - sorry] Ping? Any feedback on this patch? LGTM. cheers, grant On Thu, Mar 16, 2017 at 3:26 PM, Matthias Kaehlcke wrote: > 'perms' will never be NULL since it isn't a plain pointer but an array > of u32 values. > > This fixes the following warning when building

[PATCH] HID: remove use of DRIVER_LICENSE

Local "#define DRIVER_LICENSE" obfuscates which license is used in MODULE_LICENSE(). "fgrep -R MODULE_LICENSE" is more informative when the string is hard coded in MODULE_LICENSE. Signed-off-by: Grant Grundler <grund...@google.com> --- Most of the kernel already uses h

[PATCH] HID: remove use of DRIVER_LICENSE

Local "#define DRIVER_LICENSE" obfuscates which license is used in MODULE_LICENSE(). "fgrep -R MODULE_LICENSE" is more informative when the string is hard coded in MODULE_LICENSE. Signed-off-by: Grant Grundler --- Most of the kernel already uses hard coded strings. The f

Re: [PATCH v3 5/5] net: asix: autoneg will set WRITE_MEDIUM reg

On Thu, Sep 1, 2016 at 10:02 AM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Thu, 2016-09-01 at 12:47 -0400, Robert Foss wrote: > >> I'm not quite sure how the first From line was added, it >> should not have been. >> Grant Grundler is most definitely the a

Re: [PATCH v3 5/5] net: asix: autoneg will set WRITE_MEDIUM reg

On Thu, Sep 1, 2016 at 10:02 AM, Eric Dumazet wrote: > On Thu, 2016-09-01 at 12:47 -0400, Robert Foss wrote: > >> I'm not quite sure how the first From line was added, it >> should not have been. >> Grant Grundler is most definitely the author. >> >> Would you

Re: [PATCH 1/3] net: asix: Add in_pm parameter

On Tue, Jul 26, 2016 at 2:14 PM, Robert Foss wrote: ... > Thanks for the feedback (for this patch and the other ones)! > I'm preparing a v2 and will submit it withing a day or two. Excellent! very welcome and thanks again for picking this up. ... >> FTR, current

Re: [PATCH 1/3] net: asix: Add in_pm parameter

On Tue, Jul 26, 2016 at 2:14 PM, Robert Foss wrote: ... > Thanks for the feedback (for this patch and the other ones)! > I'm preparing a v2 and will submit it withing a day or two. Excellent! very welcome and thanks again for picking this up. ... >> FTR, current drivers/net/usb/ax88179_178a.c

Re: [PATCH 3/3] net: asix: Fix AX88772x resume failures

igned-off-by: Allan Chou <al...@asix.com.tw> Signed-off-by: WK Tsai <wk.t...@nvidia.com> Tested-by: Grant Grundler <grund...@chromium.org> Reviewed-by: Wang-Kai Tsai <gis5...@gmail.com> Reviewed-by: Mark Kuo <m...@nvidia.com> Reviewed-by: Grant Grundler <grund...@chro

Re: [PATCH 3/3] net: asix: Fix AX88772x resume failures

oglesource.com/#/q/Fix+AX88772x+resume+failures And has substantial meta data regarding author and reviewers: (summarized from https://chromium-review.googlesource.com/#/c/314520/) Signed-off-by: Allan Chou Signed-off-by: WK Tsai Tested-by: Grant Grundler Reviewed-by: Wang-Kai Tsai Reviewed-b

Re: [PATCH 2/3] net: asix: Avoid looping when the device is disconnected

On Mon, Jul 25, 2016 at 10:40 AM, wrote: > From: Vincent Palatin > > Check the answers from the USB stack and avoid re-sending multiple times > the request if the device has disappeared. > > Signed-off-by: Vincent Palatin

Re: [PATCH 2/3] net: asix: Avoid looping when the device is disconnected

On Mon, Jul 25, 2016 at 10:40 AM, wrote: > From: Vincent Palatin > > Check the answers from the USB stack and avoid re-sending multiple times > the request if the device has disappeared. > > Signed-off-by: Vincent Palatin The original chromium.org code review:

Re: [PATCH 1/3] net: asix: Add in_pm parameter

[as plain text this time...] Robert, On Mon, Jul 25, 2016 at 10:40 AM, <robert.f...@collabora.com> wrote: > From: Grant Grundler <grund...@chromium.org> For the record, I believe I am not the author of these patches. I believe the original author is Signed-off-by:

Re: [PATCH 1/3] net: asix: Add in_pm parameter

[as plain text this time...] Robert, On Mon, Jul 25, 2016 at 10:40 AM, wrote: > From: Grant Grundler For the record, I believe I am not the author of these patches. I believe the original author is Signed-off-by: Freddy Xin as recorded in the following code reviews (and test

Re: [PATCH] r8152: add MODULE_VERSION

On Fri, Jul 15, 2016 at 2:25 PM, David Miller <da...@davemloft.net> wrote: > From: Grant Grundler <grund...@chromium.org> > Date: Thu, 14 Jul 2016 11:27:16 -0700 > >> ethtool -i provides a driver version that is hard coded. >> Export the same value via &quo

Re: [PATCH] r8152: add MODULE_VERSION

On Fri, Jul 15, 2016 at 2:25 PM, David Miller wrote: > From: Grant Grundler > Date: Thu, 14 Jul 2016 11:27:16 -0700 > >> ethtool -i provides a driver version that is hard coded. >> Export the same value via "modinfo". >> >> Signed-off-by: Grant Gr

[PATCH] r8152: add MODULE_VERSION

ethtool -i provides a driver version that is hard coded. Export the same value via "modinfo". Signed-off-by: Grant Grundler <grund...@chromium.org> --- drivers/net/usb/r8152.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152

[PATCH] r8152: add MODULE_VERSION

ethtool -i provides a driver version that is hard coded. Export the same value via "modinfo". Signed-off-by: Grant Grundler --- drivers/net/usb/r8152.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index 0da72d3..1c01

Re: [PATCH v2] mmc: Set pref erase size based on size.

On Thu, Jun 2, 2016 at 5:27 PM, Gwendal Grignou wrote: > If available, eMMC stack uses HC_ERASE_GRP_SIZE as preferred erase size. > However, that size is the minimal size we must use, not the optimal size. > Calculate the optimal size based on whole device size and fall back

Re: [PATCH v2] mmc: Set pref erase size based on size.

On Thu, Jun 2, 2016 at 5:27 PM, Gwendal Grignou wrote: > If available, eMMC stack uses HC_ERASE_GRP_SIZE as preferred erase size. > However, that size is the minimal size we must use, not the optimal size. > Calculate the optimal size based on whole device size and fall back to >

Re: [PATCH net-next 2/3] r8152: modify rtl_ops_init

Hayes Wang realtek.com> writes: > Replace using VID/PID with using tp->version to initialize the ops. Hayes, This patch breaks new HW with existing drivers. more below. > > Signed-off-by: Hayes Wang realtek.com> > --- > drivers/net/usb/r8152.c | 79

  1   2   3   4   5   6   7   >