[PATCH] MEDIA CODA: Fix NULL ptr dereference in the encoder.

ctx->mb_err_cnt_ctrl could be NULL in case of failed initialization (on decoders), and encoders don't use it at all. Fixes: b2d3bef1aa78 ("media: coda: Add a V4L2 user for control error macroblocks count") Signed-off-by: Krzysztof Halasa Cc: sta...@vger.kernel.org # 5.11+ diff --

[PATCH] Marvell Sky2 Ethernet adapter: fix warning messages.

sky2.c driver uses netdev_warn() before the net device is initialized. Fix it by using dev_warn() instead. Signed-off-by: Krzysztof Halasa --- a/drivers/net/ethernet/marvell/sky2.c +++ b/drivers/net/ethernet/marvell/sky2.c @@ -4806,12 +4806,11 @@ static struct net_device *sky2_init_netdev

Re: [PATCH v5 0/6] firmware_loader: cleanups for v4.18

ader, nothing depends on it (nor the other way around), it's just (with the rest of the wanXL code) an old piece of a driver for an old card. The question is, what do we gain by messing with it? -- Krzysztof Halasa

Re: [PATCH v5 0/6] firmware_loader: cleanups for v4.18

it (nor the other way around), it's just (with the rest of the wanXL code) an old piece of a driver for an old card. The question is, what do we gain by messing with it? -- Krzysztof Halasa

Re: [PATCH v5 0/6] firmware_loader: cleanups for v4.18

68360 (the original QUICC) processor. Maximum bit rate of 2 Mb/s on each sync serial port. It's more about delivering the .S source for the firmware, I guess. Nobody is expected to build it. The fw is about 2.5 KB and is directly linked with the driver. -- Krzysztof Halasa

Re: [PATCH v5 0/6] firmware_loader: cleanups for v4.18

rocessor. Maximum bit rate of 2 Mb/s on each sync serial port. It's more about delivering the .S source for the firmware, I guess. Nobody is expected to build it. The fw is about 2.5 KB and is directly linked with the driver. -- Krzysztof Halasa

Re: [PATCH] Carrier detect ok, don't turn off negotiation

point, I don't know. Perhaps I could look at this later, but no promises (this requires pulling on and setting up some legacy hardware). Anyway, since the patch is safe and can solve an existing problem: Acked-by: Krzysztof Halasa <k...@pm.waw.pl> -- Krzysztof Halasa

Re: [PATCH] Carrier detect ok, don't turn off negotiation

Perhaps I could look at this later, but no promises (this requires pulling on and setting up some legacy hardware). Anyway, since the patch is safe and can solve an existing problem: Acked-by: Krzysztof Halasa -- Krzysztof Halasa

Re: [PATCH 13/31] timer: Remove meaningless .data/.function assignments

Kees Cook <keesc...@chromium.org> writes: > Several timer users needlessly reset their .function/.data fields during > their timer callback, but nothing else changes them. Some users do not > use their .data field at all. Each instance is removed here. For *wan/hdlc* Acked-by: K

Re: [PATCH 13/31] timer: Remove meaningless .data/.function assignments

Kees Cook writes: > Several timer users needlessly reset their .function/.data fields during > their timer callback, but nothing else changes them. Some users do not > use their .data field at all. Each instance is removed here. For *wan/hdlc* Acked-by: Krzysztof Halasa > --- a

[PATCH REPOST] Extend PCIE_BUS_PEER2PEER to set MRSS=128 to fix CNS3xxx BM DMA.

I think this bug needs to be fixed, this way or another. The platform in question is Cavium CNS3xxx, ARMv6. A recent patch by Arnd Bergmann (498a92d42596 "ARM: cns3xxx: pci: avoid potential stack overflow") converted an explicit setting of PCI_EXP_DEVCTL_READRQ = 0 (i.e., max 128 bytes for

[PATCH REPOST] Extend PCIE_BUS_PEER2PEER to set MRSS=128 to fix CNS3xxx BM DMA.

I think this bug needs to be fixed, this way or another. The platform in question is Cavium CNS3xxx, ARMv6. A recent patch by Arnd Bergmann (498a92d42596 "ARM: cns3xxx: pci: avoid potential stack overflow") converted an explicit setting of PCI_EXP_DEVCTL_READRQ = 0 (i.e., max 128 bytes for

[PATCH] Extend PCIE_BUS_PEER2PEER to set MRSS=128 to fix CNS3xxx BM DMA.

The platform in question is Cavium CNS3xxx, ARMv6. A recent patch by Arnd Bergmann (498a92d42596 "ARM: cns3xxx: pci: avoid potential stack overflow") converted an explicit setting of PCI_EXP_DEVCTL_READRQ = 0 (i.e., max 128 bytes for bus-mastering PCIe DMA read request) to: +pcie_bus_config =

[PATCH] Extend PCIE_BUS_PEER2PEER to set MRSS=128 to fix CNS3xxx BM DMA.

The platform in question is Cavium CNS3xxx, ARMv6. A recent patch by Arnd Bergmann (498a92d42596 "ARM: cns3xxx: pci: avoid potential stack overflow") converted an explicit setting of PCI_EXP_DEVCTL_READRQ = 0 (i.e., max 128 bytes for bus-mastering PCIe DMA read request) to: +pcie_bus_config =

Re: [PATCH] net: wan: wanxl.c: Cleaning up declaration of a while loop

t & PACKET_PORT_MASK) > card->n_ports) > pr_crit("%s: received packet for nonexistent port\n", -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org Mo

Re: [PATCH] net: wan: wanxl.c: Cleaning up declaration of a while loop

) pr_crit(%s: received packet for nonexistent port\n, -- Krzysztof Halasa -- 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 read the FAQ

Re: [PATCH 06/18] ARM: IXP4xx: Switch to sched_clock_register()

Stephen Boyd writes: > The 32 bit sched_clock interface now supports 64 bits. Upgrade to > the 64 bit function to allow us to remove the 32 bit registration > interface. Don't find anything wrong in this. Acked-by: Krzysztof Halasa > +++ b/arch/arm/mach-ixp4xx/common.c > @

Re: [PATCH 06/18] ARM: IXP4xx: Switch to sched_clock_register()

Stephen Boyd sb...@codeaurora.org writes: The 32 bit sched_clock interface now supports 64 bits. Upgrade to the 64 bit function to allow us to remove the 32 bit registration interface. Don't find anything wrong in this. Acked-by: Krzysztof Halasa k...@pm.waw.pl +++ b/arch/arm/mach-ixp4xx

Re: [PATCH 1/2] arm: ixp4xx: set cohorent_dma_mask for ethernet platform devices

tform device with the correct > DMA mask etc. That's also my idea. Will look at this. -- Krzysztof Halasa -- 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/majord

Re: [PATCH 1/2] arm: ixp4xx: set cohorent_dma_mask for ethernet platform devices

the platform device with the correct DMA mask etc. That's also my idea. Will look at this. -- Krzysztof Halasa -- 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

Re: [PATCH 1/2] arm: ixp4xx: set cohorent_dma_mask for ethernet platform devices

s in one place, in Ethernet driver code) was better, though not perfect. My fault is I haven't fixed it yet. Will try to invent something. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More ma

Re: [PATCH 1/2] arm: ixp4xx: set cohorent_dma_mask for ethernet platform devices

) was better, though not perfect. My fault is I haven't fixed it yet. Will try to invent something. -- Krzysztof Halasa -- 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

Re: [PATCH 7/8] ARM: ixp4xx: avoid circular header dependency

xx/include/mach/timex.h | 2 +- Acked-by: Krzysztof Halasa -- Krzysztof Halasa -- 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 read the F

Re: [PATCH 7/8] ARM: ixp4xx: avoid circular header dependency

/mach/timex.h | 2 +- Acked-by: Krzysztof Halasa k...@pm.waw.pl -- Krzysztof Halasa -- 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 read the FAQ

Re: [PATCH] Fix IXP4xx coherent allocations

the call to dma_set_coherent_mask() from within the > driver also seems to be questionable as it bypasses the "check if the > mask is possible" part of the DMA API. I thought about this for a second but the situation is the mask is guaranteed to be valid (these are on-chip devices). -- Krz

Re: [PATCH] Fix IXP4xx coherent allocations

to be questionable as it bypasses the check if the mask is possible part of the DMA API. I thought about this for a second but the situation is the mask is guaranteed to be valid (these are on-chip devices). -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-kernel

Re: [PATCH] Fix IXP4xx coherent allocations

;dev = >dev; port->plat = pdev->dev.platform_data; + dma_set_coherent_mask(>dev, DMA_BIT_MASK(32)); netif_napi_add(dev, >napi, hss_hdlc_poll, NAPI_WEIGHT); -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel&quo

Re: [PATCH] Fix IXP4xx coherent allocations

what do you think? -- Krzysztof Halasa -- 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 read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Fix IXP4xx coherent allocations

? -- Krzysztof Halasa -- 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 read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] Fix IXP4xx coherent allocations

; + dma_set_coherent_mask(dev-dev, DMA_BIT_MASK(32)); netif_napi_add(dev, port-napi, hss_hdlc_poll, NAPI_WEIGHT); -- Krzysztof Halasa -- 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

Re: [PATCH] Fix IXP4xx coherent allocations

4xx arch part makes IXP4xx's dma_set_coherent_mask() compliant with DMA API, and the actual dma_set_coherent_mask() calls in drivers are both valid and I guess recommended by the API. The patch doesn't touch the core ARM issue, that's right. -- Krzysztof Halasa -- To unsubscribe from this list: send the li

Re: [PATCH] Fix IXP4xx coherent allocations

IXP4xx's dma_set_coherent_mask() compliant with DMA API, and the actual dma_set_coherent_mask() calls in drivers are both valid and I guess recommended by the API. The patch doesn't touch the core ARM issue, that's right. -- Krzysztof Halasa -- To unsubscribe from this list: send the line

[PATCH] Fix IXP4xx coherent allocations

ARM core code currently requires coherent DMA mask to be set. Make sure we limit PCI devices to 64 MiB while allowing on-chip devices to access the whole 4 GiB address space. This fixes a v3.7+ regression which broke IXP4xx built-in network devices. Signed-off-by: Krzysztof Hałasa Cc: diff

[PATCH] Fix IXP4xx coherent allocations

ARM core code currently requires coherent DMA mask to be set. Make sure we limit PCI devices to 64 MiB while allowing on-chip devices to access the whole 4 GiB address space. This fixes a v3.7+ regression which broke IXP4xx built-in network devices. Signed-off-by: Krzysztof Hałasa k...@pm.waw.pl

Re: [PATCH] ixp4xx_eth: set the device dma_coherent_mask

't). What the driver should use is: err = dma_set_coherent_mask(xxx); (but the subsystem have to be fixed first). Also, according to DMA-API, 32-bit is the default. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord

Re: [PATCH] ixp4xx_eth: set the device dma_coherent_mask

); (but the subsystem have to be fixed first). Also, according to DMA-API, 32-bit is the default. -- Krzysztof Halasa -- 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

Re: [PATCH 5/8] wan: Remove unnecessary alloc/OOM messages

drivers/net/wan/hdlc.c| 9 - > drivers/net/wan/x25_asy.c | 1 - > 4 files changed, 10 insertions(+), 15 deletions(-) Good to see. Acked-by: Krzysztof Halasa -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

Re: [PATCH 5/8] wan: Remove unnecessary alloc/OOM messages

| 9 - drivers/net/wan/x25_asy.c | 1 - 4 files changed, 10 insertions(+), 15 deletions(-) Good to see. Acked-by: Krzysztof Halasa k...@pm.waw.pl -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord

Re: [PULL REQ] IXP4xx changes for Linux 3.7

ners, I have to quit doing this. BTW since Imre has probably even much less time, it would be a good time to find someone to maintain IXP4xx code. I will be publishing (from time to time) my tree (I'm using the hw myself), so even simple cherry-picking would probably make some sense. -- Krz

Re: [PULL REQ] IXP4xx changes for Linux 3.7

probably even much less time, it would be a good time to find someone to maintain IXP4xx code. I will be publishing (from time to time) my tree (I'm using the hw myself), so even simple cherry-picking would probably make some sense. -- Krzysztof Halasa -- To unsubscribe from this list: send the line

[PULL REQ] IXP4xx changes for Linux 3.7

ers/crypto/Kconfig | 2 +- drivers/crypto/ixp4xx_crypto.c | 12 ++-- drivers/net/wan/ixp4xx_hss.c| 2 +- 13 files changed, 59 insertions(+), 68 deletions(-) -- Krzysztof Halasa -- To unsubscribe from this list: send the line &q

[PULL REQ] IXP4xx changes for Linux 3.7

/Kconfig | 2 +- drivers/crypto/ixp4xx_crypto.c | 12 ++-- drivers/net/wan/ixp4xx_hss.c| 2 +- 13 files changed, 59 insertions(+), 68 deletions(-) -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe

Re: ARM SoC tree, Was: Re: [PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO

ntually submit a) upstream, then arm-soc and Linus' trees would work for me. I know it's a mess, but for now I have no options. BTW the situation with hardware supported only by OpenWRT is a part of the equation. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsub

Re: ARM SoC tree, Was: Re: [PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO

, then arm-soc and Linus' trees would work for me. I know it's a mess, but for now I have no options. BTW the situation with hardware supported only by OpenWRT is a part of the equation. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body

Re: ARM SoC tree, Was: Re: [PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO

better way (given the limitations), I'm open. BTW I still think I'm a part of the community, even if I don't submit code through arm-soc :-) -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kern

Re: ARM SoC tree, Was: Re: [PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO

for additional months? Doesn't "release early, release often" make sense anymore? -- Krzysztof Halasa -- 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 read the FAQ at http://www.tux.org/lkml/

ARM SoC tree, Was: Re: [PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO

ding through intermediate trees. In fact, now that I have at last a bit of spare time to work on IXP4xx again (acquired some IXP435 devices), such requirement would only mean extra workload to me. Could you please point me to a statement requiring eg. my changes to go through arm-soc? Thanks. -- Krzy

ARM SoC tree, Was: Re: [PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO

intermediate trees. In fact, now that I have at last a bit of spare time to work on IXP4xx again (acquired some IXP435 devices), such requirement would only mean extra workload to me. Could you please point me to a statement requiring eg. my changes to go through arm-soc? Thanks. -- Krzysztof

Re: ARM SoC tree, Was: Re: [PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO

. What's the _real_ reason for asking me to push my changes indirectly? Also, not that it's the most important, but how is it better for anyone to delay changes - which are completely orthogonal to arm-soc - for additional months? Doesn't release early, release often make sense anymore? -- Krzysztof

Re: ARM SoC tree, Was: Re: [PATCH 05/12] ARM: ixp4xx: use __iomem for MMIO

of the community, even if I don't submit code through arm-soc :-) -- Krzysztof Halasa -- 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 read the FAQ

Re: [PATCH 08+09/24] ARM: ixp4xx: use __iomem pointers for MMIO

XX_EXP_CFG2 = ~value; > + __raw_writel(~cpu_to_le32(value), IXP4XX_EXP_CFG2); > } The EXP_CFG2 register is already in host order, no need for cpu_to_le32() as the replaced code clearly shows. Can you merge both IXP4xx parts (in the two patches) and fix the above, please? Thanks. -- Krzyszt

Re: [PATCH 09/24] ARM: ixp4xx: use __iomem pointers for MMIO

Krzysztof Halasa writes: >> At the moment, this patch conflicts with other patches in linux-next, >> need to sort this out. > > Very nice, I will take care of these 3 patches. I mean, just this one IXP4xx patch :-) -- Krzysztof Halasa -- To unsubscribe from this l

Re: Another tree for "next"

Stephen Rothwell writes: >> >>> git://git.kernel.org/pub/scm/linux/kernel/git/chris/linux.git branch: >> >>> next > OK, I have added your tree from today. Thanks a lot. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe

Re: [PATCH 09/24] ARM: ixp4xx: use __iomem pointers for MMIO

Arnd Bergmann writes: > ARM is moving to stricter checks on readl/write functions, > so we need to use the correct types everywhere. > > At the moment, this patch conflicts with other patches in linux-next, > need to sort this out. Very nice, I will take care of these 3 patches

Re: [PATCH 09/24] ARM: ixp4xx: use __iomem pointers for MMIO

. -- Krzysztof Halasa -- 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 read the FAQ at http://www.tux.org/lkml/

Re: Another tree for next

Stephen Rothwell s...@canb.auug.org.au writes: git://git.kernel.org/pub/scm/linux/kernel/git/chris/linux.git branch: next OK, I have added your tree from today. Thanks a lot. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body

Re: [PATCH 09/24] ARM: ixp4xx: use __iomem pointers for MMIO

Krzysztof Halasa k...@pm.waw.pl writes: At the moment, this patch conflicts with other patches in linux-next, need to sort this out. Very nice, I will take care of these 3 patches. I mean, just this one IXP4xx patch :-) -- Krzysztof Halasa -- To unsubscribe from this list: send the line

Re: [PATCH 08+09/24] ARM: ixp4xx: use __iomem pointers for MMIO

(~cpu_to_le32(value), IXP4XX_EXP_CFG2); } The EXP_CFG2 register is already in host order, no need for cpu_to_le32() as the replaced code clearly shows. Can you merge both IXP4xx parts (in the two patches) and fix the above, please? Thanks. -- Krzysztof Halasa -- To unsubscribe from this list: send

Re: Another tree for "next"

on your side. Not sure about these other people/lists, added lkml. -- Krzysztof Halasa -- 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 read the FAQ at http://www.tux.org/lkml/

Re: Another tree for next

. -- Krzysztof Halasa -- 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 read the FAQ at http://www.tux.org/lkml/

Re: 3.4.10 N_GSM tty_io WARNING and lockup

ing work > is merged. I see. Thanks. -- Krzysztof Halasa -- 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 read the FAQ at http://www.tux.org/lkml/

Re: 3.4.10 N_GSM tty_io WARNING and lockup

11 pts/4Ss 0:00 \_ -sh 413 pts/4D+ 0:00 \_ [microcom] 415 pts/0D 0:00 iru -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordo

Re: 3.4.10 N_GSM tty_io WARNING and lockup

Ss 0:00 \_ -sh 413 pts/4D+ 0:00 \_ [microcom] 415 pts/0D 0:00 iru -- Krzysztof Halasa -- 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

Re: 3.4.10 N_GSM tty_io WARNING and lockup

is merged. I see. Thanks. -- Krzysztof Halasa -- 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 read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] ixp4xx: Declare MODULE_FIRMWARE usage

> \ > printk(pri "%s: " fmt, npe_name(npe), ## __VA_ARGS__) > @@ -724,6 +728,9 @@ module_exit(npe_cleanup_module); > > MODULE_AUTHOR("Krzysztof Halasa"); > MODULE_LICENSE("GPL v2"); > +MODULE_FIRMWARE(

Re: [PATCH] ixp4xx: Declare MODULE_FIRMWARE usage

+728,9 @@ module_exit(npe_cleanup_module); MODULE_AUTHOR(Krzysztof Halasa); MODULE_LICENSE(GPL v2); +MODULE_FIRMWARE(NPE_A_FIRMWARE); +MODULE_FIRMWARE(NPE_B_FIRMWARE); +MODULE_FIRMWARE(NPE_C_FIRMWARE); EXPORT_SYMBOL(npe_names); EXPORT_SYMBOL(npe_running); This looks like a good

Re: [PATCH] 2.6.25-rc2-mm1 - fix mcount GPL bogosity.

t; module abusers more cautious. Those not using _GPL exports? -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [PATCH] 2.6.25-rc2-mm1 - fix mcount GPL bogosity.

_GPL exports are really harmful - somebody distributing a binary module may claim he/she doesn't violate the GPL because the module uses only non-GPL exports. OTOH GPL symbols give _us_ exactly nothing. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-ke

Re: Tabs, spaces, indent and 80 character lines

Jan Engelhardt <[EMAIL PROTECTED]> writes: > Now back to coding, oh and don't forget send a patch for CodingStyle > since a mail without one is often taken even less seriously. Someone with a patch to Emacs to use tabs for ident + spaces for alignment maybe? :-) -- Krzy

Re: [PATCH] 2.6.25-rc2-mm1 - fix mcount GPL bogosity.

are really derivative works and it doesn't mean a module not using any _GPL exports isn't a derivative. I think introducing these _GPL symbols was a mistake in the first place. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to

Re: [PATCH] 2.6.25-rc2-mm1 - fix mcount GPL bogosity.

a module not using any _GPL exports isn't a derivative. I think introducing these _GPL symbols was a mistake in the first place. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http

Re: Tabs, spaces, indent and 80 character lines

Jan Engelhardt [EMAIL PROTECTED] writes: Now back to coding, oh and don't forget send a patch for CodingStyle since a mail without one is often taken even less seriously. Someone with a patch to Emacs to use tabs for ident + spaces for alignment maybe? :-) -- Krzysztof Halasa

Re: [PATCH] 2.6.25-rc2-mm1 - fix mcount GPL bogosity.

are really harmful - somebody distributing a binary module may claim he/she doesn't violate the GPL because the module uses only non-GPL exports. OTOH GPL symbols give _us_ exactly nothing. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message

Re: [PATCH] 2.6.25-rc2-mm1 - fix mcount GPL bogosity.

exports? -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: Tabs, spaces, indent and 80 character lines

ly possible now. >> Unpacked sources will be much bigger with not tabs, sure. >> > Without no tabs at all, you mean? With spaces in place of all tabs. All tabs converted to spaces = 20% more? "Alignment" tabs converted to spaces? How cares how much more would it t

Re: Tabs, spaces, indent and 80 character lines

space? ;) Unpacked sources will be much bigger with not tabs, sure. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: Merging of completely unreviewed drivers

code checkers find the same hotspots. I think you misunderstood. Of course I'm not against warnings in general. I'm rather talking about _authority_ of human vs machine, in this specific ("measuring" code complexity) case. -- Krzysztof Halasa -- To unsubscribe from this list: send the li

Re: Merging of completely unreviewed drivers

the same hotspots. I think you misunderstood. Of course I'm not against warnings in general. I'm rather talking about _authority_ of human vs machine, in this specific (measuring code complexity) case. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-kernel

Re: Tabs, spaces, indent and 80 character lines

with not tabs, sure. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: Tabs, spaces, indent and 80 character lines

no tabs at all, you mean? With spaces in place of all tabs. All tabs converted to spaces = 20% more? Alignment tabs converted to spaces? How cares how much more would it take if it's the correct thing. Except that it's not very practical at this point. -- Krzysztof Halasa -- To unsubscribe from

Re: Merging of completely unreviewed drivers

Pavel Machek <[EMAIL PROTECTED]> writes: >> Come on, are you doing Linux kernel development on PDA? > > I review patches on it, sometimes, yes. I take it the "sometimes" is the key word :-) -- Krzysztof Halasa -- To unsubscribe from this list: send the li

Re: Merging of completely unreviewed drivers

Pavel Machek [EMAIL PROTECTED] writes: Come on, are you doing Linux kernel development on PDA? I review patches on it, sometimes, yes. I take it the sometimes is the key word :-) -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body

Re: [ofa-general] Re: Merging of completely unreviewed drivers

> nicely wrap at 78. Sure - because email is not C code. Actually you don't "read" C code, word by word, as you read books - do you? -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECT

Re: Merging of completely unreviewed drivers

Pavel Machek <[EMAIL PROTECTED]> writes: > Zaurus is one example, second is small screen where you need big font > to keep it readable (x60 on desk). Come on, are you doing Linux kernel development on PDA? -- Krzysztof Halasa -- To unsubscribe from this list: send the line "

Re: Merging of completely unreviewed drivers

ould be free to ignore the advice. People upstream won't be fooled by some cheap tab tricks I guess. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordo

Re: Merging of completely unreviewed drivers

n looking at the code is far better at spotting such problems. Machine-generated warnings are great when the machine is actually better than human. Anyway, warnings are one thing and line limit is another. We may raise the limit leaving the 80-chars warning in place. Unless there are too many false positiv

Re: Merging of completely unreviewed drivers

such problems. Machine-generated warnings are great when the machine is actually better than human. Anyway, warnings are one thing and line limit is another. We may raise the limit leaving the 80-chars warning in place. Unless there are too many false positives, of course. -- Krzysztof Halasa

Re: Merging of completely unreviewed drivers

Pavel Machek [EMAIL PROTECTED] writes: Zaurus is one example, second is small screen where you need big font to keep it readable (x60 on desk). Come on, are you doing Linux kernel development on PDA? -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-kernel

Re: Merging of completely unreviewed drivers

. People upstream won't be fooled by some cheap tab tricks I guess. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http

Re: [ofa-general] Re: Merging of completely unreviewed drivers

email is not C code. Actually you don't read C code, word by word, as you read books - do you? -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Merging of completely unreviewed drivers

able). So I think it just have to meet the author's and reviewers' taste. We already depend on this. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.or

Re: Merging of completely unreviewed drivers

Raise the limit, terminal windows will follow. I'm using 80-column windows, too. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info

Re: Merging of completely unreviewed drivers

kernel code. Obviously printk() _output_ etc. should stay at 80. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ

Re: Merging of completely unreviewed drivers

printk() _output_ etc. should stay at 80. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: Merging of completely unreviewed drivers

, terminal windows will follow. I'm using 80-column windows, too. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http

Re: Merging of completely unreviewed drivers

have to meet the author's and reviewers' taste. We already depend on this. -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read

Re: Handshaking on USB serial devices

handshaking at all? Most (all?) UPSes I used had only TxD and RxD (for RS-232). -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: Handshaking on USB serial devices

and RxD (for RS-232). -- Krzysztof Halasa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: E1000 (PCI-E) doesn't work on nforce430, MSI issue.

"Kok, Auke" <[EMAIL PROTECTED]> writes: >>> Don't work by default. "pci=nomsi" fixes the problem. > > actually does not fix anything - it just works around it by falling > back to legacy interrupts. Actually it does, fixes the problem by working arou

E1000 (PCI-E) doesn't work on nforce430, MSI issue.

oration MCP51 Memory Controller 0 (rev a3) 00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2) Additional details on request. -- Krzysztof Halasa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo i

  1   2   3   4   5   6   7   >