Re: [PATCH 1/3] [media] si2157: get chip id during probing
>> ep: 81 l:9 08260080ff5901 >> >> here you see all the from the device. You need to be able to see the traffic on the physical I2C bus in order to help diagnose issues like this. You're going to want to see ACKS/NAKS, clocks and other I2C bus activity. You'll need to solder down scl/sda/gnd wiring to the PCB, I generally attached to the eeprom which tends to have larger pins (details on their respective datasheets). It's not hard to do, but does require a small investment in hardware. One the actual bus behavior is documented and understood, you'll likely get a better technical discussion going on. Send me a detailed picture of the PCB and I can probably help spot the I2C bus for you, if you have a low cost bus analyzer and a soldering iron. -- Steven Toth - Kernel Labs http://www.kernellabs.com
Re: [PATCH 1/3] [media] si2157: get chip id during probing
>> ep: 81 l:9 08260080ff5901 >> >> here you see all the from the device. You need to be able to see the traffic on the physical I2C bus in order to help diagnose issues like this. You're going to want to see ACKS/NAKS, clocks and other I2C bus activity. You'll need to solder down scl/sda/gnd wiring to the PCB, I generally attached to the eeprom which tends to have larger pins (details on their respective datasheets). It's not hard to do, but does require a small investment in hardware. One the actual bus behavior is documented and understood, you'll likely get a better technical discussion going on. Send me a detailed picture of the PCB and I can probably help spot the I2C bus for you, if you have a low cost bus analyzer and a soldering iron. -- Steven Toth - Kernel Labs http://www.kernellabs.com
Re: [PATCH v1 2/5] saa7164: convert to seq_hex_dump()
On Wed, Jul 9, 2014 at 11:24 AM, Andy Shevchenko wrote: > Instead of custom approach let's use recently added seq_hex_dump() helper. > > Signed-off-by: Andy Shevchenko ack Reviewed-by: Steven Toth -- Steven Toth - Kernel Labs http://www.kernellabs.com -- 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 v1 2/5] saa7164: convert to seq_hex_dump()
On Wed, Jul 9, 2014 at 11:24 AM, Andy Shevchenko andriy.shevche...@linux.intel.com wrote: Instead of custom approach let's use recently added seq_hex_dump() helper. Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com ack Reviewed-by: Steven Toth st...@kernellabs.com -- Steven Toth - Kernel Labs http://www.kernellabs.com -- 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: [v4l-dvb-maintainer] [2.6 patch] dvb/frontends/xc5000.c: make a struct static
Adrian Bunk wrote:
struct XC5000_Standard[] can become static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Reviewed-by: Steven Toth <[EMAIL PROTECTED]>
Thanks Adrian.
Mauro, please merge.
- Steve
---
e1f9c8304c807ecce026156ee2185925295fe835
diff --git a/drivers/media/dvb/frontends/xc5000.c b/drivers/media/dvb/frontends/xc5000.c
index f642ca2..a5094b7 100644
--- a/drivers/media/dvb/frontends/xc5000.c
+++ b/drivers/media/dvb/frontends/xc5000.c
@@ -151,7 +151,7 @@ typedef struct {
#define FM_Radio_INPUT221
#define FM_Radio_INPUT122
-XC_TV_STANDARD XC5000_Standard[MAX_TV_STANDARD] = {
+static XC_TV_STANDARD XC5000_Standard[MAX_TV_STANDARD] = {
{"M/N-NTSC/PAL-BTSC", 0x0400, 0x8020},
{"M/N-NTSC/PAL-A2", 0x0600, 0x8020},
{"M/N-NTSC/PAL-EIAJ", 0x0440, 0x8020},
___
v4l-dvb-maintainer mailing list
[EMAIL PROTECTED]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/v4l-dvb-maintainer
--
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: [v4l-dvb-maintainer] [2.6 patch] dvb/frontends/xc5000.c: make a struct static
Adrian Bunk wrote:
struct XC5000_Standard[] can become static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Reviewed-by: Steven Toth [EMAIL PROTECTED]
Thanks Adrian.
Mauro, please merge.
- Steve
---
e1f9c8304c807ecce026156ee2185925295fe835
diff --git a/drivers/media/dvb/frontends/xc5000.c b/drivers/media/dvb/frontends/xc5000.c
index f642ca2..a5094b7 100644
--- a/drivers/media/dvb/frontends/xc5000.c
+++ b/drivers/media/dvb/frontends/xc5000.c
@@ -151,7 +151,7 @@ typedef struct {
#define FM_Radio_INPUT221
#define FM_Radio_INPUT122
-XC_TV_STANDARD XC5000_Standard[MAX_TV_STANDARD] = {
+static XC_TV_STANDARD XC5000_Standard[MAX_TV_STANDARD] = {
{M/N-NTSC/PAL-BTSC, 0x0400, 0x8020},
{M/N-NTSC/PAL-A2, 0x0600, 0x8020},
{M/N-NTSC/PAL-EIAJ, 0x0440, 0x8020},
___
v4l-dvb-maintainer mailing list
[EMAIL PROTECTED]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/v4l-dvb-maintainer
--
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: [v4l-dvb-maintainer] [2.6 patch] media/video/cx23885/: cleanups
truct cx23885_dev *dev)
+static void cx23885_reset(struct cx23885_dev *dev)
{
dprintk(1, "%s()\n", __FUNCTION__);
@@ -636,8 +634,8 @@ static int get_resources(struct cx23885_dev *dev)
}
static void cx23885_timeout(unsigned long data);
-int cx23885_risc_stopper(struct pci_dev *pci, struct btcx_riscmem *risc,
-u32 reg, u32 mask, u32 value);
+static int cx23885_risc_stopper(struct pci_dev *pci, struct btcx_riscmem *risc,
+ u32 reg, u32 mask, u32 value);
static int cx23885_init_tsport(struct cx23885_dev *dev, struct cx23885_tsport *port, int portno)
{
@@ -837,7 +835,7 @@ static int cx23885_dev_setup(struct cx23885_dev *dev)
return 0;
}
-void cx23885_dev_unregister(struct cx23885_dev *dev)
+static void cx23885_dev_unregister(struct cx23885_dev *dev)
{
release_mem_region(pci_resource_start(dev->pci,0),
pci_resource_len(dev->pci,0));
@@ -912,6 +910,7 @@ static u32* cx23885_risc_field(u32 *rp, struct scatterlist
*sglist,
return rp;
}
+#if 0
int cx23885_risc_buffer(struct pci_dev *pci, struct btcx_riscmem *risc,
struct scatterlist *sglist, unsigned int top_offset,
unsigned int bottom_offset, unsigned int bpl,
@@ -951,10 +950,13 @@ int cx23885_risc_buffer(struct pci_dev *pci, struct
btcx_riscmem *risc,
BUG_ON((risc->jmp - risc->cpu + 2) * sizeof (*risc->cpu) > risc->size);
return 0;
}
+#endif /* 0 */
-int cx23885_risc_databuffer(struct pci_dev *pci, struct btcx_riscmem *risc,
- struct scatterlist *sglist, unsigned int bpl,
- unsigned int lines)
+static int cx23885_risc_databuffer(struct pci_dev *pci,
+ struct btcx_riscmem *risc,
+ struct scatterlist *sglist,
+ unsigned int bpl,
+ unsigned int lines)
{
u32 instructions;
u32 *rp;
@@ -981,8 +983,8 @@ int cx23885_risc_databuffer(struct pci_dev *pci, struct
btcx_riscmem *risc,
return 0;
}
-int cx23885_risc_stopper(struct pci_dev *pci, struct btcx_riscmem *risc,
-u32 reg, u32 mask, u32 value)
+static int cx23885_risc_stopper(struct pci_dev *pci, struct btcx_riscmem *risc,
+ u32 reg, u32 mask, u32 value)
{
u32 *rp;
int rc;
@@ -1243,6 +1245,7 @@ static void do_cancel_buffers(struct cx23885_tsport
*port, char *reason,
spin_unlock_irqrestore(>slock, flags);
}
+#if 0
void cx23885_cancel_buffers(struct cx23885_tsport *port)
{
struct cx23885_dev *dev = port->dev;
@@ -1253,6 +1256,7 @@ void cx23885_cancel_buffers(struct cx23885_tsport *port)
cx23885_stop_dma(port);
do_cancel_buffers(port, "cancel", 0);
}
+#endif /* 0 */
static void cx23885_timeout(unsigned long data)
{
diff --git a/drivers/media/video/cx23885/cx23885-i2c.c
b/drivers/media/video/cx23885/cx23885-i2c.c
index 71da528..12c3006 100644
--- a/drivers/media/video/cx23885/cx23885-i2c.c
+++ b/drivers/media/video/cx23885/cx23885-i2c.c
@@ -366,8 +366,6 @@ int cx23885_i2c_unregister(struct cx23885_i2c *bus)
/* --- */
-EXPORT_SYMBOL(cx23885_call_i2c_clients);
-
/*
* Local variables:
* c-basic-offset: 8
diff --git a/drivers/media/video/cx23885/cx23885.h
b/drivers/media/video/cx23885/cx23885.h
index dec4dc2..205640c 100644
--- a/drivers/media/video/cx23885/cx23885.h
+++ b/drivers/media/video/cx23885/cx23885.h
@@ -254,10 +254,6 @@ struct sram_channel {
#define cx_set(reg,bit) cx_andor((reg),(bit),(bit))
#define cx_clear(reg,bit)cx_andor((reg),(bit),0)
-extern int cx23885_sram_channel_setup(struct cx23885_dev *dev,
- struct sram_channel *ch,
- unsigned int bpl, u32 risc);
-
/* --- */
/* cx23885-cards.c*/
___
v4l-dvb-maintainer mailing list
[EMAIL PROTECTED]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/v4l-dvb-maintainer
Thanks Adrian.
Signed-off-by: Steven Toth ([EMAIL PROTECTED])
-
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: [v4l-dvb-maintainer] [2.6 patch] media/video/cx23885/: cleanups
)
{
dprintk(1, %s()\n, __FUNCTION__);
@@ -636,8 +634,8 @@ static int get_resources(struct cx23885_dev *dev)
}
static void cx23885_timeout(unsigned long data);
-int cx23885_risc_stopper(struct pci_dev *pci, struct btcx_riscmem *risc,
-u32 reg, u32 mask, u32 value);
+static int cx23885_risc_stopper(struct pci_dev *pci, struct btcx_riscmem *risc,
+ u32 reg, u32 mask, u32 value);
static int cx23885_init_tsport(struct cx23885_dev *dev, struct cx23885_tsport *port, int portno)
{
@@ -837,7 +835,7 @@ static int cx23885_dev_setup(struct cx23885_dev *dev)
return 0;
}
-void cx23885_dev_unregister(struct cx23885_dev *dev)
+static void cx23885_dev_unregister(struct cx23885_dev *dev)
{
release_mem_region(pci_resource_start(dev-pci,0),
pci_resource_len(dev-pci,0));
@@ -912,6 +910,7 @@ static u32* cx23885_risc_field(u32 *rp, struct scatterlist
*sglist,
return rp;
}
+#if 0
int cx23885_risc_buffer(struct pci_dev *pci, struct btcx_riscmem *risc,
struct scatterlist *sglist, unsigned int top_offset,
unsigned int bottom_offset, unsigned int bpl,
@@ -951,10 +950,13 @@ int cx23885_risc_buffer(struct pci_dev *pci, struct
btcx_riscmem *risc,
BUG_ON((risc-jmp - risc-cpu + 2) * sizeof (*risc-cpu) risc-size);
return 0;
}
+#endif /* 0 */
-int cx23885_risc_databuffer(struct pci_dev *pci, struct btcx_riscmem *risc,
- struct scatterlist *sglist, unsigned int bpl,
- unsigned int lines)
+static int cx23885_risc_databuffer(struct pci_dev *pci,
+ struct btcx_riscmem *risc,
+ struct scatterlist *sglist,
+ unsigned int bpl,
+ unsigned int lines)
{
u32 instructions;
u32 *rp;
@@ -981,8 +983,8 @@ int cx23885_risc_databuffer(struct pci_dev *pci, struct
btcx_riscmem *risc,
return 0;
}
-int cx23885_risc_stopper(struct pci_dev *pci, struct btcx_riscmem *risc,
-u32 reg, u32 mask, u32 value)
+static int cx23885_risc_stopper(struct pci_dev *pci, struct btcx_riscmem *risc,
+ u32 reg, u32 mask, u32 value)
{
u32 *rp;
int rc;
@@ -1243,6 +1245,7 @@ static void do_cancel_buffers(struct cx23885_tsport
*port, char *reason,
spin_unlock_irqrestore(port-slock, flags);
}
+#if 0
void cx23885_cancel_buffers(struct cx23885_tsport *port)
{
struct cx23885_dev *dev = port-dev;
@@ -1253,6 +1256,7 @@ void cx23885_cancel_buffers(struct cx23885_tsport *port)
cx23885_stop_dma(port);
do_cancel_buffers(port, cancel, 0);
}
+#endif /* 0 */
static void cx23885_timeout(unsigned long data)
{
diff --git a/drivers/media/video/cx23885/cx23885-i2c.c
b/drivers/media/video/cx23885/cx23885-i2c.c
index 71da528..12c3006 100644
--- a/drivers/media/video/cx23885/cx23885-i2c.c
+++ b/drivers/media/video/cx23885/cx23885-i2c.c
@@ -366,8 +366,6 @@ int cx23885_i2c_unregister(struct cx23885_i2c *bus)
/* --- */
-EXPORT_SYMBOL(cx23885_call_i2c_clients);
-
/*
* Local variables:
* c-basic-offset: 8
diff --git a/drivers/media/video/cx23885/cx23885.h
b/drivers/media/video/cx23885/cx23885.h
index dec4dc2..205640c 100644
--- a/drivers/media/video/cx23885/cx23885.h
+++ b/drivers/media/video/cx23885/cx23885.h
@@ -254,10 +254,6 @@ struct sram_channel {
#define cx_set(reg,bit) cx_andor((reg),(bit),(bit))
#define cx_clear(reg,bit)cx_andor((reg),(bit),0)
-extern int cx23885_sram_channel_setup(struct cx23885_dev *dev,
- struct sram_channel *ch,
- unsigned int bpl, u32 risc);
-
/* --- */
/* cx23885-cards.c*/
___
v4l-dvb-maintainer mailing list
[EMAIL PROTECTED]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/v4l-dvb-maintainer
Thanks Adrian.
Signed-off-by: Steven Toth ([EMAIL PROTECTED])
-
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] Double-free in cx23885_initdev [sls][spam-bayes]
Thanks for the patch, much appreciated. - Steve Florin Malita wrote: Both cx23885_initdev and cx23885_dev_setup free the device in their error path so a failure in the latter causes a double-free. Since cx23885_dev_setup is only called from cx23885_initdev, it should be safe to remove its deallocation and leave the cleanup up to the allocating function. Coverity CID 1922. Signed-off-by: Florin Malita <[EMAIL PROTECTED]> --- drivers/media/video/cx23885/cx23885-core.c |6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/media/video/cx23885/cx23885-core.c b/drivers/media/video/cx23885/cx23885-core.c index af16505..3cdd136 100644 --- a/drivers/media/video/cx23885/cx23885-core.c +++ b/drivers/media/video/cx23885/cx23885-core.c @@ -793,7 +793,7 @@ static int cx23885_dev_setup(struct cx23885_dev *dev) dev->pci->subsystem_device); cx23885_devcount--; - goto fail_free; + return -ENODEV; } /* PCIe stuff */ @@ -835,10 +835,6 @@ static int cx23885_dev_setup(struct cx23885_dev *dev) } return 0; - -fail_free: - kfree(dev); - return -ENODEV; } void cx23885_dev_unregister(struct cx23885_dev *dev) - 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] Double-free in cx23885_initdev [sls][spam-bayes]
Thanks for the patch, much appreciated. - Steve Florin Malita wrote: Both cx23885_initdev and cx23885_dev_setup free the device in their error path so a failure in the latter causes a double-free. Since cx23885_dev_setup is only called from cx23885_initdev, it should be safe to remove its deallocation and leave the cleanup up to the allocating function. Coverity CID 1922. Signed-off-by: Florin Malita [EMAIL PROTECTED] --- drivers/media/video/cx23885/cx23885-core.c |6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/media/video/cx23885/cx23885-core.c b/drivers/media/video/cx23885/cx23885-core.c index af16505..3cdd136 100644 --- a/drivers/media/video/cx23885/cx23885-core.c +++ b/drivers/media/video/cx23885/cx23885-core.c @@ -793,7 +793,7 @@ static int cx23885_dev_setup(struct cx23885_dev *dev) dev-pci-subsystem_device); cx23885_devcount--; - goto fail_free; + return -ENODEV; } /* PCIe stuff */ @@ -835,10 +835,6 @@ static int cx23885_dev_setup(struct cx23885_dev *dev) } return 0; - -fail_free: - kfree(dev); - return -ENODEV; } void cx23885_dev_unregister(struct cx23885_dev *dev) - 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: [linux-dvb] [PATCH] Userspace tuner
Johannes Stezenbach wrote: On Sat, Sep 15, 2007, Markus Rechberger wrote: The main discussion in this thread was about drivers in userspace are bad because the API will allow binary drivers. The guy who works for Hauppauge (again I also have good contacts at Hauppauge Europe) writes it's bad - for no technical reason. lol, oh man, how to make friends and influence people. It sends a shiver down my spine that seem to imply that you use your Hauppauge Europe contact to lobby against the efforts of Hauppauge USA employees to promote support for Open Source kernel drivers within their company. Ack. - 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: [linux-dvb] [PATCH] Userspace tuner
Johannes Stezenbach wrote: On Sat, Sep 15, 2007, Markus Rechberger wrote: The main discussion in this thread was about drivers in userspace are bad because the API will allow binary drivers. The guy who works for Hauppauge (again I also have good contacts at Hauppauge Europe) writes it's bad - for no technical reason. lol, oh man, how to make friends and influence people. It sends a shiver down my spine that seem to imply that you use your Hauppauge Europe contact to lobby against the efforts of Hauppauge USA employees to promote support for Open Source kernel drivers within their company. Ack. - 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: [linux-dvb] [PATCH] Userspace tuner
Markus Rechberger wrote: On 9/13/07, Steven Toth <[EMAIL PROTECTED]> wrote: Also there is to consider a non technical aspect, whether vendors will misuse this interface for binary only, undermining the efforts put in for OSS drivers. What holds companies for using the current available code putting it into an rpm or deb package and releasing such code now? The Avermedia example I pointed out to is a good example already. As from my side I won't release binary drivers. Although on the other side: * are drivers from vendors which work through several kernel versions that bad? * Why did someone duallicense videodev2 with BSD/GPL? I would appreciate if someone else on the list could also comment the reason that drivers should all be included in the linuxkernel just because forcing the companies to release binary drivers because of that. My opinion about that is if a company wants to go opensource they will do so, if not they will either not release a driver or release nothing. I know for certain that adding a userland API tuner/demod interface to the kernel, allowing non-caring opportunistic silicon or board vendors to developer closed source proprietary drivers, will have a negative effect on the community and we'd set back linuxtv 3-5 years. I know for certain that it would happen. Trust me. I've told you this countless times and you're not hearing me. Hauppauge have some leverage with Conexant and NXP to release public datasheets. If they just have to release a demod.so (or similar) loadable, they'll defer to the board vendors and we'll see the certain board vendors 'locking other board vendors' out of their drivers. We'll see embedded firmware, not shared between drivers. Except, it won't stop at demod.so. It will extend into unfixable bugs for VendorB's board, because VendorA doesn't want to release a new demod.so, and VendorB has no linux resources. What happens next? For financial reasons - demod.so will begin to include checks to see if specific PCI or USB devices are present in the system, and will fail to work properly (if at all) when they're not being used with the preferred products. Steven, what stops vendors of using the current existing code to achieve that goal. They could provide binary drivers with the existing API. Because the good people in this mailing list are keeping them honest. Give any board or silicon company the ability to protect their IP, even in the smallest way and they'll do it, and for no good technical reason. It's a cut throat market and it's not clear that everyone understands just how thin sales margins really are. That means Hauppauge potentially releasing a binary driver, because it's much easier than seeking silicon vendor permission for a public diver. The net result of that would mean I'd have to leave the company and find another company that practices the one thing I truly care about open source and open development groups. I'm keeping Hauppauge honest with their Linux involvement and I'm not alone. Other devs in other linux subsystems in other companies are doing the same thing. Binary drivers (or binary components) leads Linux back in time. I can't believe your so passionate about protecting secrets. What stops companies to intercept the ioctl calls and overriding some I2C commands? Why would a company want to do that? Companies don't do that, hackers do that. Since you know about windows drivers (at least I think that you know about it) you might know about the limitations of the v4l/dvb API in general the reason just put as much code as possible into the kernel just for forcing companies to release code under GPL doesn't seem to be valid. It seems perfectly valid to me. How about proprietary video formats, would you also place the decoding algorithms in kernel just to force companies to release their code for it? The kernel has no good API for those, each new type of video device and suggested API is judged on it's own merits and discussed on the mailing lists. What do you think about the existing usbfs implementation, which allows to implement usb drivers completly in userspace? Those are not my problem and I don't use them, you should raise that with the relevant usb-dev mailing lists. I'm here because I care about linuxtv. Please stay on topic. What do you think about IOMMU? Just because AMD or INTEL want to invent some whizzy new technology it doesn't say anything about the TV card development and retail business. Intel and AMD have teams of Linux engineers helping operating system developers bring their ideas and technologies to new platforms. That's a million miles away from any of the TV board vendors I know of, who have little or NO fulltime linux developers and consider the < 5% market fringe at best. Markus, senior devs in the LinuxTV group are telling you, based on their commercial experience, that userspa
Re: [linux-dvb] [PATCH] Userspace tuner
Also there is to consider a non technical aspect, whether vendors will misuse this interface for binary only, undermining the efforts put in for OSS drivers. What holds companies for using the current available code putting it into an rpm or deb package and releasing such code now? The Avermedia example I pointed out to is a good example already. As from my side I won't release binary drivers. Although on the other side: * are drivers from vendors which work through several kernel versions that bad? * Why did someone duallicense videodev2 with BSD/GPL? I would appreciate if someone else on the list could also comment the reason that drivers should all be included in the linuxkernel just because forcing the companies to release binary drivers because of that. My opinion about that is if a company wants to go opensource they will do so, if not they will either not release a driver or release nothing. I know for certain that adding a userland API tuner/demod interface to the kernel, allowing non-caring opportunistic silicon or board vendors to developer closed source proprietary drivers, will have a negative effect on the community and we'd set back linuxtv 3-5 years. I know for certain that it would happen. Trust me. I've told you this countless times and you're not hearing me. Hauppauge have some leverage with Conexant and NXP to release public datasheets. If they just have to release a demod.so (or similar) loadable, they'll defer to the board vendors and we'll see the certain board vendors 'locking other board vendors' out of their drivers. We'll see embedded firmware, not shared between drivers. Except, it won't stop at demod.so. It will extend into unfixable bugs for VendorB's board, because VendorA doesn't want to release a new demod.so, and VendorB has no linux resources. What happens next? For financial reasons - demod.so will begin to include checks to see if specific PCI or USB devices are present in the system, and will fail to work properly (if at all) when they're not being used with the preferred products. Read my lips: For commercial reasons, this enables driver components that only work if specific boards are present. - Steve - 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: [linux-dvb] [PATCH] Userspace tuner
Also there is to consider a non technical aspect, whether vendors will misuse this interface for binary only, undermining the efforts put in for OSS drivers. What holds companies for using the current available code putting it into an rpm or deb package and releasing such code now? The Avermedia example I pointed out to is a good example already. As from my side I won't release binary drivers. Although on the other side: * are drivers from vendors which work through several kernel versions that bad? * Why did someone duallicense videodev2 with BSD/GPL? I would appreciate if someone else on the list could also comment the reason that drivers should all be included in the linuxkernel just because forcing the companies to release binary drivers because of that. My opinion about that is if a company wants to go opensource they will do so, if not they will either not release a driver or release nothing. I know for certain that adding a userland API tuner/demod interface to the kernel, allowing non-caring opportunistic silicon or board vendors to developer closed source proprietary drivers, will have a negative effect on the community and we'd set back linuxtv 3-5 years. I know for certain that it would happen. Trust me. I've told you this countless times and you're not hearing me. Hauppauge have some leverage with Conexant and NXP to release public datasheets. If they just have to release a demod.so (or similar) loadable, they'll defer to the board vendors and we'll see the certain board vendors 'locking other board vendors' out of their drivers. We'll see embedded firmware, not shared between drivers. Except, it won't stop at demod.so. It will extend into unfixable bugs for VendorB's board, because VendorA doesn't want to release a new demod.so, and VendorB has no linux resources. What happens next? For financial reasons - demod.so will begin to include checks to see if specific PCI or USB devices are present in the system, and will fail to work properly (if at all) when they're not being used with the preferred products. Read my lips: For commercial reasons, this enables driver components that only work if specific boards are present. - Steve - 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: [linux-dvb] [PATCH] Userspace tuner
Markus Rechberger wrote: On 9/13/07, Steven Toth [EMAIL PROTECTED] wrote: Also there is to consider a non technical aspect, whether vendors will misuse this interface for binary only, undermining the efforts put in for OSS drivers. What holds companies for using the current available code putting it into an rpm or deb package and releasing such code now? The Avermedia example I pointed out to is a good example already. As from my side I won't release binary drivers. Although on the other side: * are drivers from vendors which work through several kernel versions that bad? * Why did someone duallicense videodev2 with BSD/GPL? I would appreciate if someone else on the list could also comment the reason that drivers should all be included in the linuxkernel just because forcing the companies to release binary drivers because of that. My opinion about that is if a company wants to go opensource they will do so, if not they will either not release a driver or release nothing. I know for certain that adding a userland API tuner/demod interface to the kernel, allowing non-caring opportunistic silicon or board vendors to developer closed source proprietary drivers, will have a negative effect on the community and we'd set back linuxtv 3-5 years. I know for certain that it would happen. Trust me. I've told you this countless times and you're not hearing me. Hauppauge have some leverage with Conexant and NXP to release public datasheets. If they just have to release a demod.so (or similar) loadable, they'll defer to the board vendors and we'll see the certain board vendors 'locking other board vendors' out of their drivers. We'll see embedded firmware, not shared between drivers. Except, it won't stop at demod.so. It will extend into unfixable bugs for VendorB's board, because VendorA doesn't want to release a new demod.so, and VendorB has no linux resources. What happens next? For financial reasons - demod.so will begin to include checks to see if specific PCI or USB devices are present in the system, and will fail to work properly (if at all) when they're not being used with the preferred products. Steven, what stops vendors of using the current existing code to achieve that goal. They could provide binary drivers with the existing API. Because the good people in this mailing list are keeping them honest. Give any board or silicon company the ability to protect their IP, even in the smallest way and they'll do it, and for no good technical reason. It's a cut throat market and it's not clear that everyone understands just how thin sales margins really are. That means Hauppauge potentially releasing a binary driver, because it's much easier than seeking silicon vendor permission for a public diver. The net result of that would mean I'd have to leave the company and find another company that practices the one thing I truly care about open source and open development groups. I'm keeping Hauppauge honest with their Linux involvement and I'm not alone. Other devs in other linux subsystems in other companies are doing the same thing. Binary drivers (or binary components) leads Linux back in time. I can't believe your so passionate about protecting secrets. What stops companies to intercept the ioctl calls and overriding some I2C commands? Why would a company want to do that? Companies don't do that, hackers do that. Since you know about windows drivers (at least I think that you know about it) you might know about the limitations of the v4l/dvb API in general the reason just put as much code as possible into the kernel just for forcing companies to release code under GPL doesn't seem to be valid. It seems perfectly valid to me. How about proprietary video formats, would you also place the decoding algorithms in kernel just to force companies to release their code for it? The kernel has no good API for those, each new type of video device and suggested API is judged on it's own merits and discussed on the mailing lists. What do you think about the existing usbfs implementation, which allows to implement usb drivers completly in userspace? Those are not my problem and I don't use them, you should raise that with the relevant usb-dev mailing lists. I'm here because I care about linuxtv. Please stay on topic. What do you think about IOMMU? Just because AMD or INTEL want to invent some whizzy new technology it doesn't say anything about the TV card development and retail business. Intel and AMD have teams of Linux engineers helping operating system developers bring their ideas and technologies to new platforms. That's a million miles away from any of the TV board vendors I know of, who have little or NO fulltime linux developers and consider the 5% market fringe at best. Markus, senior devs in the LinuxTV group are telling you, based on their commercial experience, that userspace access is technically
Re: [linux-dvb] SAA7160/2
Manu Abraham wrote: Hi All, After a bit of talks with NXP, they stated that if shown enough of a user base (future business forecast) for the SAA7160 / SAA7162 PCIe chipset, they would take into consideration, an investment into support, such that the chips can be better supported. ie, i need to provide them information that there is some significant numbers in the user base. Additionally, vendors such as Azurewave are ready to help us as well, in whatever way they can. Any ideas, how we can show user support in terms of a future business case ? Comments appreciated. Hi manu, Hauppauge deal with NXP on a daily basis. We have a number of 716x products either in the market or coming to market and we can add some leverage. I can push this through our FAE and account manager. Who's your contact at NXP that we should make reference to? Email me privately and we can work together on this. Regards, Steve - 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: [linux-dvb] SAA7160/2
Manu Abraham wrote: Hi All, After a bit of talks with NXP, they stated that if shown enough of a user base (future business forecast) for the SAA7160 / SAA7162 PCIe chipset, they would take into consideration, an investment into support, such that the chips can be better supported. ie, i need to provide them information that there is some significant numbers in the user base. Additionally, vendors such as Azurewave are ready to help us as well, in whatever way they can. Any ideas, how we can show user support in terms of a future business case ? Comments appreciated. Hi manu, Hauppauge deal with NXP on a daily basis. We have a number of 716x products either in the market or coming to market and we can add some leverage. I can push this through our FAE and account manager. Who's your contact at NXP that we should make reference to? Email me privately and we can work together on this. Regards, Steve - 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/
