Question from developers

Hello, we are a software house specializing in software development and cloud services. We provide our clients with cloud service support and security, as well as Office 365 management. We have been operating in the market for over 13 years, during which many companies like yours have benefite

Question

Hello, Are you looking for more B2B leads for your company? We are selling a database of more than 313 thousand companies in South Africa. Over 215 Thousand emails, 106 Thousand cells, and 226 thousand phones. I have attached a sample for your reference. It is categorized into 2084 different i

[engineering.redhat.com #494100] Question on submitting patch for a security bug

Hello Navid, On Thu, 18 Jul 2019 01:30:20 GMT, emamd...@umn.edu wrote: > I've found a null dereference bug in the Linux kernel source code. I was > wondering should I cc the patch to you as well (along with the > maintainers)? No. Please do not cc on the upstream kernel patches. It is meant for

[PATCH 0/4] staging:rtl8192u: Style and a question?

o the style and readability of the code. My question is with respect to the member variable 'enabled' which has been refactored in the third patch of the series. I've renamed the variable to 'dot11d_enabled', (in addition to changing it's type as suggested by checkpat

Re: Question about disabling of CONFIG_ANDROID_BINDER_IPC_32BIT in upcomng kernel 4.18

cted by his mail bot > > I a few words the question is: > > Has CONFIG_ANDROID_BINDER_IPC_32BIT been removed > in 1190b4e38f97023154e6b3bef61b251aa5f970d0 ("ANDROID: binder: remove > 32-bit binder interface") > for a mandatory reason (incompatibilty with Android P bui

Re: Question about disabling of CONFIG_ANDROID_BINDER_IPC_32BIT in upcomng kernel 4.18

+ de...@linuxdriverproject.org resending to Greg KH as instructed by his mail bot I a few words the question is: Has CONFIG_ANDROID_BINDER_IPC_32BIT been removed in 1190b4e38f97023154e6b3bef61b251aa5f970d0 ("ANDROID: binder: remove 32-bit binder interface") for a mandat

Re: ks7010 endianness question

> I think we can call this question resolved. Remove the comment and > change the hostif_hdr description to > > struct hostif_hdr { > __be16 size; > __be16 event; > } __packed; > > Are you happy with this? Yes, I trust you. signature.asc

Re: ks7010 endianness question

On Wed, Apr 19, 2017 at 01:34:46PM +1000, Tobin C. Harding wrote: > Hi Wolfram, > > May I please ask you with an ks7010 driver endianness question? > > Comments on the hostif_hdr data structure (ks_hostif.h) state that the > target uses little endian byte order. > > /

ks7010 endianness question

Hi Wolfram, May I please ask you with an ks7010 driver endianness question? Comments on the hostif_hdr data structure (ks_hostif.h) state that the target uses little endian byte order. /* * HOST-MAC I/F data structure * Byte alignmet Little Endian */ struct hostif_hdr { u16 size

Quick Question

Hey there, Not sure if you got my last email but wanted to touch base again. I was wondering if you wanted to try our email marketing and lead generation solutions. We can help to grow your business fast by using our services. We have worked on a number of projects and campaigns, all our packages

Re: lustre: question about lov_request.c

On Jun 8, 2015, at 3:24 AM, Julia Lawall wrote: >> You are right, set_pga seems to be a dead member. It was alive a once, but >> somehow not fully removed now, >> so it's safe to drop the whole if and also the struct member itself. >> set_oabufs could be dropped as well. > > Looking further,

Re: lustre: question about lov_request.c

> You are right, set_pga seems to be a dead member. It was alive a once, but > somehow not fully removed now, > so it's safe to drop the whole if and also the struct member itself. > set_oabufs could be dropped as well. Looking further, in the same function I also don't see any other uses o

Re: lustre: question about lov_request.c

On Sun, 7 Jun 2015, Drokin, Oleg wrote: > Hello! > > You are right, set_pga seems to be a dead member. It was alive a once, but > somehow not fully removed now, > so it's safe to drop the whole if and also the struct member itself. > set_oabufs could be dropped as well. Thanks. I will do

Re: lustre: question about lov_request.c

Hello! You are right, set_pga seems to be a dead member. It was alive a once, but somehow not fully removed now, so it's safe to drop the whole if and also the struct member itself. set_oabufs could be dropped as well. Thanks. Bye, Oleg On Jun 7, 2015, at 4:11 PM, Julia Lawall wrote

lustre: question about lov_request.c

Hello, The function lov_finish_set in drivers/staging/lustre/lustre/lov/lov_request.c contains the code: if (set->set_pga) { int len = set->set_oabufs * sizeof(*set->set_pga); OBD_FREE_LARGE(set->set_pga, len); } If I change the call to OBD_FREE_LA

Re: Question about the function,ni_stc_dma_channel_select_bitfield

n he tries to go around the vger ban by > emailing developers directly as he did here. > > greg k-h > Greg Kh, Sorry about that :(, your absolutely right I need to listen more to the community. After thinking about it your right that was a terrible question in nature and I should have assumed based off the code that my assumptions were right. Nick ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: Question about the function,ni_stc_dma_channel_select_bitfield

On Wed, May 06, 2015 at 10:05:55AM -0400, nick wrote: > On 2015-05-06 05:10 AM, Ian Abbott wrote: > > On 06/05/15 01:22, nick wrote: > >> Greetings All, > >> I am wondering if in the function,ni_stc_dma_channel_select_bitfield the > >> line: > >> return 1 << channel; > >> is guaranteed to be below

RE: Question about the function,ni_stc_dma_channel_select_bitfield

On Wednesday, May 06, 2015 7:06 AM, nick wrote: > On 2015-05-06 05:10 AM, Ian Abbott wrote: >> On 06/05/15 01:22, nick wrote: >>> Greetings All, >>> I am wondering if in the function,ni_stc_dma_channel_select_bitfield the >>> line: >>> return 1 << channel; >>> is guaranteed to be below the thresho

Re: Question about the function,ni_stc_dma_channel_select_bitfield

On 2015-05-06 05:10 AM, Ian Abbott wrote: > On 06/05/15 01:22, nick wrote: >> Greetings All, >> I am wondering if in the function,ni_stc_dma_channel_select_bitfield the >> line: >> return 1 << channel; >> is guaranteed to be below the threshold that guarantees us to not overflow on >> a unsigned

Re: Question about the function,ni_stc_dma_channel_select_bitfield

On 06/05/15 01:22, nick wrote: Greetings All, I am wondering if in the function,ni_stc_dma_channel_select_bitfield the line: return 1 << channel; is guaranteed to be below the threshold that guarantees us to not overflow on a unsigned 32 integer due to bit wise shifting to the left. Thanks Nick

Question about the function,ni_stc_dma_channel_select_bitfield

Greetings All, I am wondering if in the function,ni_stc_dma_channel_select_bitfield the line: return 1 << channel; is guaranteed to be below the threshold that guarantees us to not overflow on a unsigned 32 integer due to bit wise shifting to the left. Thanks Nick _

Re: Question regarding sparse warning in staging/lustre

ession_new_ioctl(lstio_session_new_args_t __user *args) > > > { > > > char *name; > > > int rc; > > > > > > The warning turns to: > > > > > > drivers/staging/lustre/lnet/selftest//conctl.c:825:13: warning: > > >

Re: Question regarding sparse warning in staging/lustre

ot;console.h" > > > > static int > > -lst_session_new_ioctl(lstio_session_new_args_t *args) > > +lst_session_new_ioctl(lstio_session_new_args_t __user *args) > > { > > char *name; > > int rc; > > > > The warning turns to: > >

Re: Question regarding sparse warning in staging/lustre

char *name; > int rc; > > The warning turns to: > > drivers/staging/lustre/lnet/selftest//conctl.c:825:13: warning: dereference > of noderef expression > > Now the question: > Is this right or it is just a false warning from sparse? > Should

Question regarding sparse warning in staging/lustre

; static int -lst_session_new_ioctl(lstio_session_new_args_t *args) +lst_session_new_ioctl(lstio_session_new_args_t __user *args) { char *name; int rc; The warning turns to: drivers/staging/lustre/lnet/selftest//conctl.c:825:13: warning: dereference of noderef expression Now t

Re: question regarding drivers/staging/rtl8821ae/rtl8821ae/dm.c

On Wed, Aug 13, 2014 at 01:06:16AM +0530, Himangi Saraogi wrote: > Hi, > > In the file, I see the code: > > void rtl8821ae_dm_set_tx_ant_by_tx_ > info(...) { >   ... >   if ((rtlefuse->antenna_div_type == CG_TRX_HW_ANTDIV) || >       (rtlefuse->antenna_div_type == CG_TRX_HW_ANTDIV)){ >      SET_T

Re: Question about further cleanup in staging/bcm

EBUG() macros > > question: Should I simply _remove_ them, or should they be > replaced by something else? Also: When? After the last iteration, > I guess? Most of them will be deleted in the end. The ones that stay will be in a better format

Question about further cleanup in staging/bcm

y concerns about this? Would you guys like to see these patches? Are there more issues to solve I don't see yet? Please send me your suggestions! TODOs listed in the TODO file I would like to solve: * remove developer debug BCM_DEBUG() macros question: Should I simply _remove_ them, or

Re: question regarding drivers/staging/iio/adc/ad7280a.c

On Thu, Jul 17, 2014 at 01:58:15PM -0700, Greg Kroah-Hartman wrote: > On Thu, Jul 17, 2014 at 11:40:04PM +0530, Himangi Saraogi wrote: > > Hi, > > > > I have sent in a patch for adding devm_kasprintf > > https://lkml.org/lkml/2014/7/ > > 16/667. > > I will be updating this file and send in a patc

Re: question regarding drivers/staging/iio/adc/ad7280a.c

On Thu, Jul 17, 2014 at 11:40:04PM +0530, Himangi Saraogi wrote: > Hi, > > I have sent in a patch for adding devm_kasprintf https://lkml.org/lkml/2014/7/ > 16/667. > I will be updating this file and send in a patch once it is accepted. Was it > the right thing > to do to send the devm_kasprintf pa

Re: question regarding drivers/staging/iio/adc/ad7280a.c

sure that everything is freed as it should be, in the right order. The question here is whether such a memory leak squashing would be worth applying to stable. Personally I'd go with no. In which case feel free to fix it via the introduction of a devm version. devm is probably fine here. The

Re: question regarding drivers/staging/iio/adc/ad7280a.c

the right order. The question here is whether such a memory leak squashing would be worth applying to stable. Personally I'd go with no. In which case feel free to fix it via the introduction of a devm version. Jonathan Thanks Himangi ___

Re: Question about patches for bcm

On Thu, Jun 26, 2014 at 04:42:11PM +0200, Matthias Beyer wrote: > Hi, > > I have a question related to some patches I send in. > > (I send them to de...@driverdev.osuosl.org, but they show up in the > archives of this list... so I'm asking here) > > I send 6 patc

Re: Question about patches for bcm

Argh, I forgot to send the patches. Sorry about that... a lot of stuff is going on here atm. I think it would be best if I start CCing you for all new patchsets I send. So I don't have to resend them all which would probably confuse people ... Hope you're fine with this? -- Mit freundlichen Gr

Re: Question about patches for bcm

-2014 11:11:40, Kevin McKinney wrote: >>On Thu, Jun 26, 2014 at 11:02 AM, Matthias Beyer >>wrote: >> >> On 26-06-2014 10:58:20, Kevin McKinney wrote: >> > A A On Thu, Jun 26, 2014 at 10:42 AM, Matthias Beyer >> >> > A A w

Re: Question about patches for bcm

A wrote: > > > > A A A Hi, > > > > A A A I have a question related to some patches I send in. > > > > A A A (I send them to de...@driverdev.osuosl.org, but they show up > in the > > A A A archives of this l

Re: Question about patches for bcm

On 26-06-2014 10:58:20, Kevin McKinney wrote: >On Thu, Jun 26, 2014 at 10:42 AM, Matthias Beyer >wrote: > > Hi, > > I have a question related to some patches I send in. > > (I send them to de...@driverdev.osuosl.org, but they show up in the >

Question about patches for bcm

Hi, I have a question related to some patches I send in. (I send them to de...@driverdev.osuosl.org, but they show up in the archives of this list... so I'm asking here) I send 6 patch sets since the beginning of the month. Some of them where reviewed, some not. None of them is upstream b

Re: staging: dgap: Question about declaring variables

There isn't a rule for that. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: staging: dgap: Question about declaring variables

On 05/22/2014 04:38 PM, Dan Carpenter wrote: > On Thu, May 22, 2014 at 01:49:22PM -0400, Mark Hounschell wrote: >> I understand that unnecessarily initializing them is wrong. But if they >> do need initialized, is it preferred to do it in the declaration or in >> the code before it is used? > > Wh

Re: staging: dgap: Question about declaring variables

On Thu, May 22, 2014 at 01:49:22PM -0400, Mark Hounschell wrote: > I understand that unnecessarily initializing them is wrong. But if they > do need initialized, is it preferred to do it in the declaration or in > the code before it is used? Which ever is more clear. It's up to you. Or do you me

staging: dgap: Question about declaring variables

I understand that unnecessarily initializing them is wrong. But if they do need initialized, is it preferred to do it in the declaration or in the code before it is used? Thanks Mark ___ devel mailing list de...@linuxdriverproject.org http://driverdev.li

[RFC] staging: dgap: sparse warning question

I get the sparse warning: drivers/staging/dgap/dgap.c:367:25: warning: too long initializer-string for array of char It's referring to INIT_C_CC in the following code segment. static struct ktermios DgapDefaultTermios = { .c_iflag = (DEFAULT_IFLAGS), /* iflags */ .c_of

Re: Question about staging drivers

On Fri, Feb 21, 2014 at 10:37:26AM -0500, Mark Hounschell wrote: > When a kernel subsystem undergoes a global change such as the serial > subsystem has been since 3.5 or so, if a driver is in staging, does it > automatically get those changes if they are applicable to it? Yes. If you change an AP

Re: Question about staging drivers

On Fri, Feb 21, 2014 at 10:37:26AM -0500, Mark Hounschell wrote: > When a kernel subsystem undergoes a global change such as the serial > subsystem has been since 3.5 or so, if a driver is in staging, does it > automatically get those changes if they are applicable to it? Yes it does.

Question about staging drivers

When a kernel subsystem undergoes a global change such as the serial subsystem has been since 3.5 or so, if a driver is in staging, does it automatically get those changes if they are applicable to it? Thanks Mark ___ devel mailing list de...@linuxdriver

Re: vme_tsi148 question

On Thu, Feb 6, 2014 at 12:40 AM, Martyn Welch wrote: > > > On 05/02/14 23:21, Michael Kenney wrote: >> >> On Wed, Feb 5, 2014 at 1:38 PM, Michael Kenney wrote: >>> >>> On Wed, Feb 5, 2014 at 1:22 PM, Martyn Welch wrote: On 5 February 2014 17:41, Greg KH wrote: > >>>

Re: vme_tsi148 question

On 05/02/14 23:21, Michael Kenney wrote: On Wed, Feb 5, 2014 at 1:38 PM, Michael Kenney wrote: On Wed, Feb 5, 2014 at 1:22 PM, Martyn Welch wrote: On 5 February 2014 17:41, Greg KH wrote: On Tue, Feb 04, 2014 at 06:34:13PM +, Martyn Welch wrote: On 04/02/14 16:34, Michael Kenney

Re: vme_tsi148 question

On Wed, Feb 5, 2014 at 1:38 PM, Michael Kenney wrote: > On Wed, Feb 5, 2014 at 1:22 PM, Martyn Welch wrote: >> >> >> >> On 5 February 2014 17:41, Greg KH wrote: >>> >>> On Tue, Feb 04, 2014 at 06:34:13PM +, Martyn Welch wrote: >>> > On 04/02/14 16:34, Michael Kenney wrote: >>> > >Hi Martyn,

Re: vme_tsi148 question

On Wed, Feb 5, 2014 at 1:22 PM, Martyn Welch wrote: > > > > On 5 February 2014 17:41, Greg KH wrote: >> >> On Tue, Feb 04, 2014 at 06:34:13PM +, Martyn Welch wrote: >> > On 04/02/14 16:34, Michael Kenney wrote: >> > >Hi Martyn, >> > > >> > >On Tue, Feb 4, 2014 at 7:28 AM, Martyn Welch > > >

Re: vme_tsi148 question

On Tue, Feb 04, 2014 at 06:34:13PM +, Martyn Welch wrote: > On 04/02/14 16:34, Michael Kenney wrote: > >Hi Martyn, > > > >On Tue, Feb 4, 2014 at 7:28 AM, Martyn Welch >> wrote: > > > >On 28/12/13 00:34, Michael Kenney wrote: > > > >Hi Martyn, > > > >

Re: vme_tsi148 question

On 04/02/14 16:34, Michael Kenney wrote: Hi Martyn, On Tue, Feb 4, 2014 at 7:28 AM, Martyn Welch mailto:martyn.we...@ge.com>> wrote: On 28/12/13 00:34, Michael Kenney wrote: Hi Martyn, On Fri, Dec 27, 2013 at 4:23 PM, Martyn Welch mailto:mar...@welchs.me.uk>> wrote

Re: vme_tsi148 question

On 28/12/13 00:34, Michael Kenney wrote: Hi Martyn, On Fri, Dec 27, 2013 at 4:23 PM, Martyn Welch wrote: On 27/12/13 20:15, Michael Kenney wrote: We are using the vme_tsi148 bridge driver along with the vme_user driver to access the VME boards. The A/D board requires D32 bus cycles and the V

Re: vme_tsi148 question

On Tue, Jan 14, 2014 at 1:39 AM, Martyn Welch wrote: > On 14/01/14 04:07, Michael Kenney wrote: >> Unfortunately, the results are the same. I'm running this from home so >> I'll have to confirm with the logic-analyzer tomorrow but the bridge >> driver error messages suggest the same D8 writes (whi

Re: vme_tsi148 question

On 14/01/14 04:07, Michael Kenney wrote: > Unfortunately, the results are the same. I'm running this from home so > I'll have to confirm with the logic-analyzer tomorrow but the bridge > driver error messages suggest the same D8 writes (which for some > reason our A/D board does not like). The ha

Re: vme_tsi148 question

Hi Martyn, On Mon, Jan 13, 2014 at 6:49 AM, Michael Kenney wrote: > Hi Martyn, > > On Mon, Jan 13, 2014 at 4:00 AM, Martyn Welch wrote: > [snip] >> >> Hi Mike, >> >> I'm a little bemused by this one - I haven't managed to replicate it yet. I >> have a feeling that the VME driver in version 3.2

Re: vme_tsi148 question

Hi Martyn, On Mon, Jan 13, 2014 at 4:00 AM, Martyn Welch wrote: [snip] > > Hi Mike, > > I'm a little bemused by this one - I haven't managed to replicate it yet. I > have a feeling that the VME driver in version 3.2 won't use 16-bit transfers > at the beginning of blocks that aren't naturally ali

Re: vme_tsi148 question

On 07/01/14 16:14, Michael Kenney wrote: > Hi Martyn, > > On Fri, Dec 27, 2013 at 4:34 PM, Michael Kenney wrote: >> >> Hi Martyn, >> >> On Fri, Dec 27, 2013 at 4:23 PM, Martyn Welch wrote: >>> On 27/12/13 20:15, Michael Kenney wrote: We are using the vme_tsi148 bridge driver along with

Re: vme_tsi148 question

Hi Martyn, On Fri, Dec 27, 2013 at 4:34 PM, Michael Kenney wrote: > > Hi Martyn, > > On Fri, Dec 27, 2013 at 4:23 PM, Martyn Welch wrote: > > On 27/12/13 20:15, Michael Kenney wrote: > >> > >> We are using the vme_tsi148 bridge driver along with the vme_user > >> driver to access the VME boards.

Re: vme_tsi148 question

Hi Martyn, On Fri, Dec 27, 2013 at 4:23 PM, Martyn Welch wrote: > On 27/12/13 20:15, Michael Kenney wrote: >> >> We are using the vme_tsi148 bridge driver along with the vme_user >> driver to access the VME boards. The A/D board requires D32 bus cycles >> and the VME master window is configured a

Re: vme_tsi148 question

possible. I've heard of this happening recently, but haven't yet been able to replicate it. Which VME board are you running Linux on and which flavour of Linux? If there is a more appropriate mailing-list for this question, please let me know. This is the correct lis

vme_tsi148 question

-list for this question, please let me know. Thanks. --Mike - Michael Kenney Ocean Engineering Dept Applied Physics Lab University of Washi